Jump to content

NRV

Members
  • Content Count

    436
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by NRV

  1. Don't know why, but in the last tests, if I do "save frame" with "PAL artifacting" (and only with that artifacting mode), the black backgrounds is a light gray instead..
  2. Nice... never used it, but always believed the common myth about it, that the overflow bit indicates a carry (or overflow) from bit 6.. x)
  3. That's the correct "generic" way of doing it, but you also could have different logic for different "quadrants" for the ray (centered in the viewpoint position). So, for example, a ray moving in a "top-left" direction, could check X against the 0 limit and Y against the 256 limit only (assuming coordinate Y grows from "bottom" to "top"). Also, you normally trace rays from left to right ("clockwise"), so you don't change "quadrants" that often.
  4. I have not seen your code, but the basic algorithm should be something like: loop: - sync to some screen line - show screen buffer 1 work on screen buffer 2: - erase previous sprites in buffer 2 (needs a list of the positions and sprite types previously drawn in buffer 2) - update real sprite positions (and animations, creation, destruction..) - draw sprites in buffer 2 (save positions/types in list for buffer 2) - sync to some screen line - show screen buffer 2 work on screen buffer 1: - erase previous sprites in buffer 1 (needs a list of the positions and sprite types previously drawn in buffer 1) - update real sprite positions (and animations, creation, destruction..) - draw sprites in buffer 1 (save positions/types in list for buffer 1) jump loop:
  5. Have you tried using "speed control: trigger" ? Maybe that way is easier to move at the low speed, and then you can accelerate only when you need it
  6. I have very little play time with any of them, but here is my vote: 1. Gravity Worms 2. Dungeon Hunt II 3. Fruity Pete 4. The Rescue Expedition 5. Berks Four 6. Star Vagrant 7. Castle Defender 8. Jet Set Willy 2019 9. Imogen 10. Monty on the Run
  7. Thanks everyone! About ABBUC, well it wasn't ready on time and I didn't want to wait for the next one x) So maybe I should do something new for this year.. Here is a video (in not-like-a-man's form) from VinsCool, with the soundtrack of the game:
  8. So, somehow a char based, software sprite demo, ended as a game.. We started iterating on this in 2018, with MrFish, but after some months we had to stop for different reasons. At that point the game was already very playable, with the classic levels, so it was kind of sad not publishing it, so people could play it. Then at the end of 2019 I had some time to improve it and finish some features, but it ended with a lot more things added x). VinsCool started working on it and did all the great music (all 3 arcade tunes and more). Therealbountybob did testing and proposed some nice improvements (and also made a case for the PAL version). Synthpopalooza did his magic and created some great sound effects. MrFish came back to do more art and propose new ideas. So, what is this? (from the Readme.txt): Raymaze 2000 is an action game, based on the Taito arcade game Raimais (from 1988), but is not a direct port. It has a set of 14 levels based on the original ones, with classic enemies and powerups, but also adds a lot of new things: - a new branch of 17 original levels - new enemy behaviors - some new powerups and secrets - improved controls and also new ways of controlling your vehicle - 3 difficulty levels (Casual, Medium, Expert) - other new gameplay ideas (Raimais could be seen as an improved version of Head On, or maybe Pac-Man, something like what Taito did with Breakout/Arkanoid or Qix/Volfied). NTSC vs PAL: If you want to play in the emulator, then is better to choose the NTSC version. Not only because of the 60 fps, but also because the game speeds, colors, music, sounds, were first created for NTSC and later translated for PAL. Both versions are pretty similar anyway, let's say over 95%.. but there are some things you cannot replicate perfectly, like the colors and some timings. Future developments: The memory of a 64K computer is almost full, so I will need to create a proper .atr version, with loading, if I want to add anything. We had a lot of ideas between MrFish and I, that we would like to test at some point, but who knows when that will be. But because of that we could say that this is version "0.5" of the game that we had in mind :). Contents of the zip: Raymaze_2000_NTSC.xex (the main version), Raymaze_2000_PAL.xex, Readme.txt (a mini manual), plus some game screens. The game needs an A8 computer with 64K. The .xex start loading from memory address $2800 (10K), but at the end it loads a final segment over an address near $2000 (8K), so I hope it works without problems in real hardware. Enjoy! Raymaze 2000.zip
  9. If you don't need "source" updated at the end, you could just use Y: .export _plot_bitmap_fast destination = $d4 ; address of gfx buffer source = $d6 ; address of 16 byte array .proc _plot_bitmap_fast ldy #0 loop: lda (source), y eor (destination),y sta (destination),y iny ; point to second byte lda (source), y eor (destination),y sta (destination),y iny lda destination clc adc #40-2 bcc no_inc inc destination+1 no_inc: sta destination cpy #8*2 bne loop ; and write the next row of bytes exit_fast_plot: rts .endproc
  10. Well, there is the recent research done in this thread, starting from this post: But I haven't seen anyone talking about important differences, between different machines..
  11. I was thinking about something similar once, but how do you define the "next frame"?. Using VBlank?, similar vcount value?, same code instruction? (assuming the same code is triggered the "next frame"), end of the display list? start of the next one? ...
  12. Is there a document about the debug features, other than the help menu in Altirra and the help from the command line in the debugger? I'm a new (noob) user of the debugger and would like to know a little about the Watch windows, and some examples for the use of the heatmap. I started using the ##trace and ##assert commands from a mads listing, and they are great for logging values and checking conditions. But for my current problem, it would be great to be able to enable/disable "asserts" from the source, or something similar. My idea would be to trap any write to a small table, when it comes from "invalid" code only. Would you say this is already possible, using conditional breakpoints (bx) and using a condition like "(pc != valid_code_adr1) and (pc != valid_code_adr2) ..", listing all the valid code addresses? Also, would it be too difficult (or slow) to have a Memory window that is updated once per frame? I know about the watch commands, but sometimes you need more than 8 watches
  13. Could you do things like following the player from side to side with the camera, or small bobs up and down according to the bumps in the track? (also for the camera, with a spring or sine-like smoothing). Maybe allowing the ships to "jump" when hitting bumps, or rolling a little when moving from side to side.. also projecting a fake shadow in the ground (a black circle/ellipse sprite would be enough). There is a lot of small details that would allow you to "sell" more the 3d effect, but I don't know how flexible is your current engine / 3d pipeline.. And after that, things like allowing the camera pitch to change according to the pitch of the track, or allowing the camera to roll a little if there are turn sections.. Would be too much work to generate your track points procedurally? Regards.
  14. 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..
  15. 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
  16. 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.
  17. 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
  18. 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.
  19. ?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.
  20. 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
  21. 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.
  22. 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..
  23. 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..
  24. One Joe from Panama? More now that you can have your own levels..
×
×
  • Create New...