Jump to content

NRV

Members
  • Content Count

    436
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by NRV

  1. A new proposal.. well mostly what I would do if I had all the time in the world x). Trying to go for the arcade real proportions, using software sprites in G15, narrow field, and starting by using only 4 colors: Using 4 colors to display all the graphics in the game works pretty good, because that seems to be a limit of the hardware (4 colors per sprite). Later, with the game already running, you could decide what to do with all the player/missiles. Like use them for the layer of stars, the hud, the player's ship, to add color to some enemies (like the top ones), for the tractor beam, etc. You probably could add colors via DLI's to the stars, without the need to use WSYNC, so that would be pretty cheap in processing time. The normal arcade screen has a resolution of 224x288 pixels, and you need at least 236 scan lines to display the top enemies and the player's ship. That's a number the A8 could display in theory, with overscan (in normal mode Altirra can show 224 scan lines). Been this a graphics mode, you could use some display list tricks, like "compressing" the screen by removing some evenly spaced lines (by skipping them in the display list, adding LMS instructions to jump over them). Then you could offer the player some configurations like "full" screen, removing 8 lines, removing 16 lines, etc. And you wouldn't need to change your sprite code, it would be totally transparent (memory would still be continuous). Another option to remove a line could be alternating it with the next line, every other frame. Kind of a compressed interlacing, also just by updating the display list. You could also offer quality vs speed options to display the sprites, like properly masked, using xor, or just plain byte replace. With more memory (or a cart version), you could go for precompiled sprites. In X you have half the resolution, with 112 G15 pixels, so narrow field is good enough. You have 8 extra pixels per side, that I used here to show the level "medals" and the number of lives, as an example (with a dark grey background, that could be done with a couple of missiles). This could complicate side clipping, but that's a problem for another time x). Why using the arcade resolution? .. mostly to use the original movement patterns and logic. Also, no home version seemed to have used it, so the A8 conversion would be something special. Well Namco already did the work to convert the arcade code (three Z80 processors) to 6502, with the NES version. They adapted the game for a normal home TV display (from the vertical arcade orientation), adjusting the moving patterns, shortening the tractor beam, moving the player's ship 40 scan lines up, and removing the vertical "expansion" in the resting enemies at the top. Still, the game feels pretty similar to the original. We could use those patterns (and maybe the logic code). But, I would prefer to port the arcade version
  2. NRV

    Baby Pac-Man

    And.. who told you this one is "simple"? I mean, I was part of a team doing a comercial Arkanoid-like game once and the "physics" for that (well, mostly collision detection and reactions) were easier, because you can search for known equations and algorithms, and you can use a good math library. But doing something similar in a 6502 with limited memory is a lot more difficult, because you normally start from zero, and need to get very creative with the limited resources. I would say that is the real problem here, but now that you know you can start working on that Probably nobody here wants you to do this in a fixed frame of time, so take the time you need and have fun. And ask for help when you need it Working with coordinates in one byte is easier than working with two, but in the end it will depend on how many times you need to convert from one "side" to the other. What are you going to prioritize, memory or processing time.. Are you also going to use sub pixel precision (more bytes) for the positions and speeds? Inclusive if you choose one option now, you may want to change it later, but I would vote for one byte positions for now (for the "integer" part at least).
  3. NRV

    Baby Pac-Man

    From the things I have done with trajectories and different angles, I always assume that the pixel ratio is 2:1. Sure, is not going to look perfect in NTSC or PAL (probably no one would notice), but then there are optimizations you can do with angles and speed tables, where changing an X component to Y just means multiplying by 2 or dividing by 2.
  4. This is an "old" experiment to use char based software sprites, with source included. Plus a nice intro using pcm 4+4 samples, with the screen on (the only reason for this to use a 1MB cartridge). Many thanks to MrFish for improving the original graphics, adding color to the level, and creating that nice car Features: - 10 cars with logic to check collisions and move through the maze, every car with a different speed and acceleration. - char based, pre shifted and pre compiled software sprites (with sizes that changes between 2x3, 3x2 and 2x2 chars). - full copy of the background and proper masking for every sprite. - NTSC, 60 fps, with free time to do 1 or 2 more cars probably (more in PAL). - double buffered screen (40x25, antic4 graphic mode) and font. - some DLI's used through the screen, to add extra color (no interleaved fonts). I did a second version of this, but without using pre compiled sprites. Reading the data from tables I could display 7 cars in more or less the same time (not bad I suppose). But after my experiments with software sprites years ago, I was a little disappointed with the results that I got. I mean, using software sprites in a bitmap mode is a lot simpler and probably faster in some cases, than using the same resolution in a char mode. For example, if you have many small sprites (let's say 4x2 pixels) in char mode, you are going to need to touch (copy) a lot more memory, than using those same sprites in graphic mode (in average). And in general you are going to move more memory in a char mode, for sprites of the same (small - medium) size. The good thing with using chars is that you can get an extra color, or do some visual tricks just plotting chars, or maybe do font animations without touching the screen data. And restoring the screen ("erasing" the sprites), should be faster than in a graphic mode. Probably with bigger sprites, using chars is a win-win. Pre shifted and pre compiled sprites use a lot of memory by definition. In this case the car has 28 frames (4 going right, 4 going left, 4 diagonals, 8 going up, 8 going down), that amounts to something below 12KB. I probably could reduce that number to something below 9KB, by optimizing the size of the 16 frames for the vertical movement, that also include the empty space at the start and end of the car (to pad to the height of 3 chars). I did it like that just because it was faster and easier to implement. The pre-shifted frames are also used to have the tires animation, so they have more reason to exist. rdemo_carts.zip rdemo_source.zip
  5. NRV

    Baby Pac-Man

    That link also points to this demo/game: http://www.pouet.net/prod.php?which=24499 That has a video.. (physics seems pretty good) And the full source code is available (6502). It has some equations with sin and cos, but they seem to be only precalculated tables. The amount of memory needed could be a problem with this technique, but maybe it could work well with lower res maps.
  6. Not that I know I'm not sure what a cartridge boot bypass is in this case..
  7. I did some experiments with the screen "on", sometime ago, and this is one of them. Music was provided by Rybags, from the RoadBlasters arcade game (who has a Yamaha chip and a Pokey ). roadb.zip Source and 1MB carts provided.. (NTSC and PAL). At some point I was going for this: But I don't have the cpu time to activate the players for now. That would need another round of optimization and a little of luck The code can play different tracks, in a sequence set in a table, so maybe it can be useful for someone. Colors are done using a table indexed by VCOUNT. Animation is done completely by Antic Samples played using PCM4+4, at 8 bit depth, and 15720 Hz (one sample per scan line).
  8. After that post, Extra mode was added, and that is more like a "tower" with 2 levels per "floor" In Extra mode you start in level A1 and have 2 options (left - right) in every level: A1 -> B1/B2 -> C1/C2 -> D1/D2 ... The previous modes (easy, casual, arcade) still have the "tree" structure: 1A -> 2A/2B 2A -> 3A/3B 2B -> 3B/3C ...
  9. Thanks! It works perfectly for the temporary label: ?GLOBAL_LABEL = 1 org $1000 .macro M_test1 ?GLOBAL_LABEL = 2 .def :?GLOBAL_LABEL = 3 .print ?GLOBAL_LABEL .print :?GLOBAL_LABEL lda #0 .endm M_test1
  10. Is it possible to change the value of a global label (temporary or not) from inside a macro? When I try to do things like: ?GLOBAL_LABEL = 1 GLOBAL_LABEL2 = 10 org $1000 .macro M_test1 ?GLOBAL_LABEL = 2 //:?GLOBAL_LABEL = 3 .print ?GLOBAL_LABEL .print :?GLOBAL_LABEL GLOBAL_LABEL2 set 20 //:GLOBAL_LABEL2 set 30 .print GLOBAL_LABEL2 .print :GLOBAL_LABEL2 lda #0 .endm M_test1 The ?GLOBAL_LABEL and GLOBAL_LABEL2 inside the macro are just different labels. And the commented lines both throw different errors..
  11. Two things to look at: - The order of the updates is important, what goes first, the player update or the moving platform update (and the camera update). - The camera has its own speed and acceleration (well, the speed depends on the distance to the player and there is a min and max speeds). Is possible that the jitter comes from the constant "catch up" from the camera to the player's position. Try playing with the speed of the moving platform, or maybe changing the camera logic when the player is on a moving platform.
  12. Nice! I played the .xex a little, would look at the code later The platform movement is better, don't know yet why the first and last chars have that small jitter. The laser animation slowdown seems to be just a visual thing. You kind of get the same effect when walking left or right. Probably adding more animation frames to the lasers will solve it. Walking over a moving platform seems a little weird sometimes, maybe when doing small movements. Kind of like the player movement cannot keep up with the platform movement. The ladder "attach" point seems perfect now. Regards.
  13. My examples are for 15.7 KHz approx. and 8 bit depth, don't know if that works for you? That's one sample per scanline, using wsync. I also interleaved the data, first a 4K block for the left channel and then a 4K block for the right channel, for every cart bank. I would clean the code and put it here later. Edit: here is the source: clean.zip Would you say that there is more noise than what we get in Altirra? I don't have any experience with the mac version, but I assume that drag and drop or "Attach cartridge.." don't work? Here are my last examples in .car format: Atari.zip (the _rh versions, ntsc and pal)
  14. Yes, in the case of my examples first you need to mount the bin in Altirra as a cart type "42*: MaxFlash 1M .. (bank 127)". After that you go to "Save Firmware / Save Cartridge" and save it as a ".car" file. You can also mount my examples in Altirra as type "*MaxFlash 1M .. (bank 0)", but then you cannot save them as a ".car" later.
  15. Those wonderful moments where you are finishing your code and try a final improvement, that just move your critical path code over the 105 cycles per line. Then you cannot live with the imperfection.. so you end moving all the code to page 0 just for 6 extra cycles. First, the pal version of the previous file, that I forgot: stereo.zip Then a new sample (from Marble Madness arcade), that clearly shows the stereo effect. Check the ntsc version in the emulator if you can, the wave visualization is nice stereo2.zip I tried to have the smaller delay between changing the left and right channels, but I really don't know if that delay could produce some kind of audio artifact or not.
  16. Well, this is real stereo, but the effect is kind of subtle. Will try a better sample later and with less noise. stereo.zip
  17. I did a quick test with the same song playing in both channels (left / right) and at least in emulation it seems alright. So, can someone test the "_rh" versions in real hardware (1 MB carts for NTSC or PAL)? Probably would try to do a real stereo test later (is a little more complicated, but should not be much more). The "_emu" versions sound good in Altirra with the stereo configuration (and louder than mono). monox2.zip
  18. Nice changes in your version. You already have music and sound effects. Is kind of funny seeing Bounty Bob destroyed by a laser Your moving platform seems to work well. It would be nice if you can make the movement "per pixel" instead of "per char" (for the player and the platform). One way could be having 3 more chars per side (6 in total) with the different offsets for the platform left and right sides. Or having 2 special chars per platform, for the left and right borders, and you update the content every frame. All this assuming the middle section of the platform doesn't have a visual pattern that also needs to be updated. Other option could be using player/missile graphics, but then you need special code to check that collision. Don't know how you made the player move with the platform, but if I were to implement moving platforms I probably would put the player in a special state, or maybe save the "id" of the platform where the player is walking, and later add any delta movement of that platform also to the player. Also, probably it would be better if you define now ladders with two chars, the left and right sides, so you can lock the player horizontal position to the center of the ladder. Having swimming and climbing animations would be great Yep, when I told you that I changed the NMI handler that also means that the OS rom is disabled in my version, so probably your "jsr SETVBI" is going nowhere. I think I didn't use the ram under the OS so probably you can switch it back, or never disable it (look for the macro "DisableOperatingSystem"). But if you only need it to set a VBI you could also call your code where I told you before, inside the bottom DLI (maybe you would need to save the X register also, and restore it later). Regards. (Damn.. all this time and I never saw that there was a missing "t" in the title )
  19. I haven't looked at your changes, but in my original version I change the NMI handler to point to the only DLI, and the VBI is not enabled. You can put your code inside that DLI if your only interest is doing some changes once per frame (like calling RMT's update). Is there a xex with your changes in there? I don't think you want to play digital sound, so forget about wav's for now.
  20. Haha of course! Maybe we are a little spoiled.
  21. Next game by Sheddy confirmed then? Something more intellectual to go with the latin then: (don't hate me Phaeron x) )
  22. I have the same doubt about the setup. Probably Phaeron and Xuel can explain it better. I would need to see some graphics to really understand how this technique works x) Yep, I assumed 114 cycles for a scan line, without the 4 cycles for the next STA STIMER (110 different values, range from 0 to 109 for every sample). For my 31KHz experiment I used 57-4 = 53 different values. Sure. I was waiting for people checking on more hardware, for the correct setup values. Right now my previous PCM4+4 examples (ex PDM) only work in Altirra. But it seems the values found by Phaeron are good to go (X=3, Y=5). So here are the previous PDM examples converted for real hardware and also in .car format: pdm_carts_rh.zip At least in Altirra 3.10 test24 they should sound bad for now (with noise). The PWM examples in the thread, already have .car files included. By the way I generated the .car by saving the .bin from inside Altirra (with "Save Firmware"). Regards.
  23. Nothing fancy I think.. I normally start with a 44KHz or 48KHz wav file. Sometimes I take a look at it with Audacity and apply a Normalize effect there. But in general I use a sox command like this: sox --no-dither --norm song.wav --type raw --encoding un --channels 1 --rate 15720 --bits 8 song_ntsc_15k.raw or: sox --no-dither --norm song.wav --type raw --encoding un --channels 1 --rate 15600 --bits 8 song_pal_15k.raw That means no dither, default normalize level (could use also --norm=2, or --norm=3, if you want more volume and don't mind some clipping), generate a raw file without headers, unsigned numbers (0 - 255 in this case), mono, the specific rate for your project (one sample per scanline in this case, ntsc or pal), and 8 bits depth (one byte per sample). You can use the same kind of command to generate a wav file, if you want to look at it with Audacity: sox --no-dither --norm song.wav --type wav --encoding un --channels 1 --rate 15720 --bits 8 song_ntsc_15k.wav For example to see if you are using the full amplitude range. Other rates I have used for my ntsc examples: 7860 (every two scan lines), 21013, 31440. In my final experiments I was using the rate command as an effect, because you can use more parameters like this: sox --no-dither mix2.wav --type raw --encoding un --channels 1 --bits 8 mix2_15k_ms.raw rate -m -s 15720 It would be better that you read the Sox documentation for the explanation of the "-m -s" parameters, but after experimenting with the quality settings that was the option that sounded better for me. I also experimented with the compand command: sox --no-dither song.wav --type wav song_amp.wav compand 0.3,1 6:−70,−60,−20 −5 −90 0.2 This one, with the same parameters, is explained in the documentation. It's a kind of "normalization" but can apply different levels in different parts of the song. Well, after all this you have an 8 bit song that can be directly used in the A8, with the pcm4+4 (ex pdm) technique. But if you wanted to use the pwm technique, for example at 15720 Hz (one sample per scanline), you need to reduce the 0-255 range to something like 0-109. For that I used a script in C# where the algorithm is a simple scaling like this: private void ByteArrayRemapRange(byte[] byteArray, int arraySize, byte minValue, byte maxValue, byte newMinValue, byte newMaxValue) { for (int i = 0; i < arraySize; i++) { float remapFactor = (float)(newMaxValue - newMinValue) / (maxValue - minValue); float newValue = (byteArray[i] - minValue) * remapFactor + newMinValue; int newValueInt = Mathf.RoundToInt(newValue); byteArray[i] = (byte)newValueInt; } } This lives in a Unity project, along other code that I use to transform data to the A8 needs, so is not exactly a useful tool right now
  24. PCM44 because of the 44KHz rate?, could be.. Well you could do it at other rates also... PCMX?, the X could be for extra, extended, xuel.. Hope you document all your ideas at some point (could be in the wiki). Maybe some of them doesn't have an application now, but you never know who could use them later
  25. Updated code to play the "song 2" and the "megamix" with the PDM technique. Also included the 1Mb cart images for both, and in NTSC and PAL versions. pdm_carts.zip Now it plays at 15.7KHz (15.6KHz in pal), with 8 bits of depth, same memory usage as before, without the carrier tone. Also there is no click sound at the end, the wave fits on the screen, and it can be aborted with the start key. A win-win x) .. thanks to Xuel and kool kitty89. So maybe the conclusion of this thread is to not use PWM and only use PDM when possible
×
×
  • Create New...