Jump to content

NRV

Members
  • Content Count

    397
  • Joined

  • Last visited

  • Days Won

    2

NRV last won the day on September 1 2017

NRV had the most liked content!

Community Reputation

392 Excellent

About NRV

  • Rank
    Moonsweeper

Recent Profile Visitors

15,928 profile views
  1. Nope, that's not how you do it. You can have smooth animation and movement of your software sprites, in a char based mode, over a detailed and scrolling background (if you want), without requiring a lot of memory. And in some cases it could be faster than doing the same in bitmap mode.. but that analysis would be for a long post x) You don't need to have every combination of a sprite and background in memory (well.. if you have the memory, then that would be faster :)). What you do is to reserve some some chars in the font for your sprite, and when you want to draw it to the screen, you put those chars over the background. THEN you write the same background info that was there before, INTO the memory in the font, for those chars. After that you write the sprite data over that same font memory, using proper masking (and, ora instructions). There is some extra details, but that's the general idea..
  2. I have done some old experiments with software sprites and I'm also a "macro lover", for precompiled sprites x) From what I remember there were different ideas used, but sadly neither of the examples used a scrolling background. A more recent one, for char software sprites (also with source): https://atariage.com/forums/topic/282434-char-based-software-sprites One interesting thing in the macros of the last one, is that the "write byte" part was "aware" of the previous byte, so it can generate consecutive "sta" if writing the same byte: .macro MACRO_DRAW_BYTE .if (([%%1%%3] == 0) && (:?DRAW_STA_OPT_FLAG == 1) && (:?DRAW_STA_OPT_VALUE == [%%2%%3])) sta (m_newCharFontAddress),y .elseif ([%%1%%3] == 0) // mask byte == 0 ? (only new byte then) lda #[%%2%%3] sta (m_newCharFontAddress),y .def :?DRAW_STA_OPT_FLAG = 1 .def :?DRAW_STA_OPT_VALUE = [%%2%%3] .elseif ([%%1%%3] == $FF) // mask byte == $FF ? (only old byte then) lda (m_oldCharFontAddress),y sta (m_newCharFontAddress),y .def :?DRAW_STA_OPT_FLAG = 0 .else lda (m_oldCharFontAddress),y and #[%%1%%3] // invert the mask here? (in another place is better) ora #[%%2%%3] sta (m_newCharFontAddress),y .def :?DRAW_STA_OPT_FLAG = 0 .endif .if (:4 == 0) iny .endif .endm Anyway, I still think is better to write an external tool to generate the precompiled sprite code
  3. What I used in my clone, to avoid a ball trapped in an "infinite" loop, was using a counter to track the number of times the ball hits unbreakable bricks. If that number gets to 100, I change the current angle of the ball slightly, and reset the counter to 0. Also, if the ball hits any other type of brick, the paddle or an enemy, the counter is also reset to 0. Maybe some powerups could also reset the counter.
  4. If you need help with some of the rules there is always the StrategyWiki: https://strategywiki.org/wiki/Arkanoid/Getting_Started There was an old utility to edit the levels inside the arcade roms, don't know if this is the one that you used: http://www.ionpool.net/arcade/arkedit/arkedit.html I don't know if the probability for every type of capsule is documented somewhere.. well, in the source For my own clone I assigned this values: E (enlarge, expand) 50/256 D (disrupt.. multi ball, x3) 40/256 P (extra player) 4/256 C (capture ball, catch) 51/256 S (slow ball) 31/256 B (next board, break) 2/256 These should add to 256, but I don't have the Laser, and have another type of powerups. Some other rules that I implemented, looking at the behaviors in Arkanoid: - don't throw the same bonus when that power is still active (E,C,S,L, maybe D) - don't throw the same bonus two times in a row - there is a small possibility that a marked brick doesn't throw a capsule (I used 16/256) - if we are moving at min speed don't give the "slow" bonus - allow only one extra player bonus per level
  5. But, but... it was BlueMoon_001 that called the music top notch... is not like they are.. the same person.. They just have the same tastes, write the same way and dislike people that "nitpick". Perfectly normal if you ask me.
  6. ?varX = 0 .rept nosprites :4 .byte >(sprites+14*#*4+?varX*14*4*4) ?varX++ .endr Don't remember about nested repts, but something like this should work.. Working example from some code: ?cy = 0 .rept ITEM_MATRIX_SIZEY :ITEM_MATRIX_SIZEX .byte <[screenBuffer1+LINE_SIZE+1+[?cy*3*LINE_SIZE+3*#]] ?cy++ .endr I believe nested repts were added in the last few years, but you should test it.
  7. I haven't used git much, but I still would vote for it, instead of hg. I think probably is going to be easier to plot the trajectories taking screenshots in Mame Aaaargh.. you made me look for the sounds and I drifted far away x) If you want to take a "look" at the Nes sounds: https://www.sounds-resource.com/nes/galagademonsofdeath/sound/4033/ Or prefer a version for the 2600: (there is source down the page) http://atariage.com/forums/topic/214498-galaga-2600-sound-test/ And this app for the Ipad is really nice: https://itunes.apple.com/us/app/korg-gadget/id791077159?mt=8 It seems Namco made available there, the sounds of lots of old arcade games.. including Galaga, Xevious, PacMan, etc. The nice thing is that it models a Waveform Sound Generator, like the sound chip in the old Namco arcade games, so you can see how the sounds were constructed, in all detail. You can see in the video the wave table (of 32 steps) for some of the sounds. Bonus tracks.. two translations of the same interview: http://shmuplations.com/galaga/ https://galaga.com/en/special/int_vol1.php And a nice site that I didn't knew about https://retrocomputing.stackexchange.com/questions/4733/how-did-z80-multiprocessing-work-in-the-namco-galaga-hardware
  8. I forgot that I already did 10 char pre compiled sprites, of a similar size, in my recent demo.. duh. With just preshifted sprites I did like 7 or 8 in one frame, and with a bitmap mode I think I would get better or similar results (for sprites of that size). So doing 8 software pre shifted sprites (plus logic) doesn't sound that crazy in G15 (NTSC, 60fps). Don't know if the test_big in this thread is going at 60Hz? But the size of the sprites is similar at what I would like to use. Also I think we can reduce the memory requirements, for the pre shifted data, in half.. by creating a draw routine that use the sprite data backwards. Kind of a "free" vertical flip in hardware I see this as a friendly discussion to share ideas. There are similar ones from time to time. Probably many of the people that could cooperate already have projects going on, or just don't have the time. So I wouldn't expect a coordinate effort, but I can be wrong At least I know that I would like to finish the sprite sheet for G15 (4 colors) and do the display routines, if someone provides me with the arcade movement data I forgot about those.. some of them could be useful, but I would change the colors to the ones I used on my gif Wouldn't like to go to G7, but.. that would solve all the speed and memory problems. At the expense of worse graphics and coarser vertical movement.
  9. Haha.. forget it! Wolf or something similar would go in a 1MB. If you want content, textures, music, levels, then give me the memory . Look at the good side.. it would run on a 64KB system For Galaga I think you still can have a very good version in 64KB. Use xor for sprite drawing, then you don't need masks. Don't use pre shifting (there is no memory anyway). The key question would be if you can create a draw routine, that could display 10 moving enemies (8?) in one frame (easier in PAL). Maybe you could use only one pre shifted frame (4 bits rotation) and less sprite rotations..
  10. Another vote for the horizontal expansion. The vertical one would be nice, but I can live without it. The NES version looks ok without using it, I think. You also need someone to finish the sprite sheet, for all the ships with 15 degree rotations: The arcade game and the NES have it easy, because it seems they have hardware to flip any sprite horizontally and vertically. They have double the horizontal resolution of the A8, but use one quarter of the data, so in the end they use half the memory needed for the A8 version. Well, a lot less if you add the sprite masks (that the A8 needs for properly masked sprites). If you go for all the sprites, that is something like 292 frames of 32 bytes (assuming 8x16 pixels, G15), so 9344 bytes. If you want pre shifted sprites that means adding 14016 x 3, for a total of 51392 bytes (just the ships). Then you need to add the masks (or just use xor or replace, to draw the sprites). A version for 64K probably would need to use less rotation frames and no pre shifting. A version for 128K could use pre shifting, but would need less rotation frames also. A deluxe version, with pre compiled sprites and everything would go in a 1MB cart Well, at least when you have the data in G15 mode, generating different draw methods is pretty easy. I always wanted to do a demo with just the challenging stages. Would be enough as a proof of concept. So if someone with Z80 knowledge can look at the available source (that have some comments from what I remember), and locates the data for the movement patterns, that would be nice x) Another way to get that data could be to look at the Mame driver for Galaga. Locate the hardware registers that control the sprite position and "orientation" data, and add some code to log the data written to those registers every frame. Or go for the Space Harrier way..
  11. One Joe from Panama? More now that you can have your own levels..
  12. 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
  13. 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).
  14. 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.
  15. 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
×
×
  • Create New...