Jump to content

NRV

Members
  • Content Count

    436
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by NRV

  1. I went back and did my last "megamix" in pdm 8 bits at 15.7Khz. I was already using one byte per sample so the memory consumption is the same and there is no carrier frequency. I don't know about real hardware, but in emulation it sounds reeeeally nice. Come one.. what's next.. a 320x200 mode with 16 colors? Stop moving the goalpost guys mixpdm.zip
  2. Nice! Two questions.. would doing: lda hi,x ldy lo,x sta audc2 sty audc1 instead of: lda hi,x sta audc2 lda lo,x sta audc1 ..improve anything? And do you think it still would sound good at 15.7 KHz?
  3. And the last one.. A one-minute "megamix" of songs from old arcade games. There is a NTSC version and a PAL version this time, 1 MB cart bins as always. Maybe I should give a prize to the people that can name them all Regards. mixcarts.zip
  4. And here it is.. 32 seconds, cart almost full. cart.zip
  5. With 15KHz you can leave the screen "on" in any graphics mode probably. And at least in narrow playfield (32 bytes wide), with the menu "on" (the six lines of graphic 0) it sounded almost equal to me. First scan line of a char line is "nasty" for the timing, but it seems ok with this.. should test it more anyway. I would try to do the second song in 31KHz later, it just fit in the 1Mb cart.
  6. Hi. I 've been doing some testing of the PWM technique to play samples (thanks Phaeron and Xuel for the examples). Is nothing great, but I think that maybe the code could be of use to people doing similar experiments. It's for a 1Mb cart and there are two small songs only, but in different qualities. The options are: 1 - Song 1, PWM at 15720 Hz, sample values between 0 and 109, a little lower than 7bit depth. "Normal" PWM quality, with one sample per scan line. 2 - Song 1, PWM at 21013 Hz, sample values between 0 and 80, higher than 6bit depth. This is a failed experiment.. I tried to play 4 samples every 3 scan lines, but getting the perfect timing for this seems impossible, because of the refresh cycles. I wasn't that far off, but the small imperfections in timing are enough to add an undesired frequency sound. 3 - Song 1, PWM at 31440 Hz, sample values between 0 and 52, lower than 6bit depth. This worked well but it eats memory x) (30 seconds max for a 1Mb cart). This plays two samples per scan line, the timing was a little tricky because you need to avoid the refresh cycles and also balance your worst case code branch with the rest of the code. The good thing is that the normal carrier frequency produced by PWM (that at 15KHz is still annoying for some people) is not an issue. The bad thing is that playing more samples in the same time, implies that the bit depth is lower (for PWM).. so at the end of the day I don't think this is an improvement over the 15KHz PWM. 4 - Song 1, at 15720 Hz, sample values between 0 and 15, classic 4bit depth. This could sound better, but I didn't allowed much clipping, so maybe the volume is too low. 5 - Song 2, PWM at 15720 Hz, same as the first option, but with a larger song. The 15720 Hz rate sounds perfect in NTSC and just a bit slower in PAL (there the rate should be 15600 Hz). All samples converted with Sox and then with some scripts in C#, to move the data to the correct range allowed by every method. Main code is in rtech_cart.asm, done in Mads. I think that using 15KHz PWM is an improvement over the classic 4bit sound, if you are playing songs without much silence (where the 15Khz carrier frequency can bother some people). Also you can do some simple track sequencing with the screen on, so a nice intro for a game in a 1MB cart can use this. I already have code for this, but that's coming later pwm.zip
  7. Hi! Just a little "quality of life" update to this.. version 1.84 with some small changes. The changelog is inside the "pad.asm" file as always, but basically: - Added intro music by Miker, at the start of a level. - Added sound effects for losing a life, for an extra life and for picking a powerup. - Created a sound priority system for the sound effects. - Added visual effect for the open exits at the end of a level. - Increased mouse control min speed (at least in emulation it feels better, hope someone in real hardware can test it someday). - Plus other small improvements. All code included. Any feedback is welcome. Picture with all current levels: Small video: Regards! Pad_1_84.zip
  8. Sure, go ahead. It's here to be used
  9. That island deserves its own game x) I think you should test how it looks while moving, maybe an animated gif could be enough to see if there is any unanticipated "weirdness" going on.. But at least the bullets should use the mask, they look a lot better that way.. and they are small, so the rendering cost should be low. Now.. if Popmilo's test don't appear soon enough, someone else could be tempted to do them
  10. Haha, if you are going to do it, full animation frames would be better and more flexible Below the sun area you have 3 color registers available (you used two colors in the current sun reflection). The falling star could be done with players, in the screen area over the sun. The top of the sun is done with all the players at the end, so if there are small birds they should fly between the sun and the heroes (small area), or just over the sun. Also, try to use the even luminances in the 256 color palette (0, 2, 4, .. 14), if you want a direct conversion for the A8
  11. What?, Why?? Never knew that Mario did the pitfall/spelunker thing.. That, or drugs are bad when trying to port a game. Out of jokes, I think it's surprising that for any old game that I search, no matter how obscure, the Nes seems to have a port of it..
  12. I agree with both of you, but not for now x) I also wanted to do that. Doing the movement with fine scrolling should be "easy". Probably it would be better to merge the movement and the "sparkle" into animation frames, but someone would need to provide them to me At some point I started looking at sunset gif's: Other ideas: a falling star at the end, the sun setting down slowly, some stars appearing at the top of the sky, the heroes jumping from the cliff..
  13. Mini development blog: The background color is changed every line with a big DLI, that starts at the top of the screen, and ends several scan lines after the bottom of the screen. After the section of the DLI that controls the background colors, we do a lot of other things, like playing the RMT music, managing the logic state of the demo, or resetting some registers for the next frame. There is no VBI, and the main code loop only have a "Here jmp Here" instruction. If you want to see how much time is available per frame, just hold any CONSOL key (and set Altirra's overscan mode to "full"). Apart from changing the background colors, the "main" section of the DLI also modify other color registers, the P/M's (positions, colors and size) and the Prior register (yep, the timing was tight sometimes, so self modifying code was used in some points). The title and the sun graphics are done in g15 mode. A part of the sun, the heroes and the terrain are done using all the P/M's. The scrolling text is in char mode Antic4. The demo has 5 internal states: - The title fade-in is done changing the value of 3 color registers. - The background fade-in is done changing one pointer, so the DLI code take the background colors from a new table. - The movement of the sun is done with horizontal fine scrolling (and updating the LMS's in the display list), using a wide screen mode. At the same time the P/M's position is updated. - The movement of the title image that leaves the screen is done changing the LMS pointer for that area in the display list (no use of VSCROL here). At the same time, to avoid crossing a 4K area, or having a lot of empty memory after the image, I just start writing blank line instructions directly into the display list. - When starting the movement of the scrolling text we change the display list for another with char lines. Also we change the wide playfield mode to use narrow mode. This helps with the timing for the DLI, because of the badline for every char line used. The movement of the text is done using vertical scrolling and updating the top LMS, as usual. The color masks at the top and bottom are done updating the char colors. The only tricky part is the bottom mask, where you also need to change the P/M's priority per line (between been in top, and been behind). There is no pal version for now. It would mean changing the colors, adjusting the times for every part and changing the music. Trying to do 2 RMT's calls in the same frame could be difficult, but PAL has more time per frame. I don't know if that would sound correct. The only "bad" thing of the NTSC version is that the sun looks "thin", if you use the correct pixel ratio (at least in Altirra). There are a lot of comments in the code for anyone that want to take a look, but also many hard coded numbers x) This was a fast, "just program, don't think" job, most of the time
  14. Haha.. I was afraid you would say something like that. Hope you don't mind the small changes, most of them were forced by the hardware limits The heroes lost some weight.. The one thing that I miss the most, are the subtle color changes for the background, thanks to the 7800 being able to use its 256 color palette there.. I did what I can to not miss any detail, but in a couple of lines I had to "dither" some dark orange zones.
  15. Hey Fragmare! Go figure.. less than a week later, someone found a port of the Solaria's intro for the A8 computers, and with source included x) http://atariage.com/forums/topic/277766-solarias-code/ I'm just leaving this here.. maybe something can be useful to 7800 programmers.. (difficult, but you never know ) Regards.
  16. Hi, couldn't resist doing this.. Here is a port of the Solaria "teaser" done for our A8's (ntsc version only for now). The original palette used the 256 colors of the 7800, so it loses some of the more subtle color variations of the background, but is more or less the same. Also the scrolling text doesn't start from the bottom.. that maybe can be done, but it would be a pain in the ass x) It can be moved down right now, but it doesn't look that good starting near the sun (it loses legibility). I used most of the assets that Fragmare posted here http://atariage.com/forums/topic/277344-sword-of-solaria-final-fantasy-style-jrpg-7800-graphicsmusic-mockup/ Would post a video and talk more about the code later (source and all files included). Regards! Solaria.zip
  17. Really like that mockup Just 4 colors because is bitmap graphics?, what would be the grey color at the top of the ship then? And was black not the background color just to get blue at the borders? I had my old demo/mockup with a similar idea: Char graphics, 2 players for the player's ship and weapons, 2 players for the enemies (moving enemies or static in the terrain) and the missiles for most of the enemy shots, but probably is a little limiting (in gameplay terms) doing it like that. I was thinking of something similar, having the full game running at 30 fps (25 in pal) to be able to do things that you don't see normally in the A8. This old demo scrolls the screen once every two frames, and I think it looks good enough: But thinking about your examples, I assume that we are talking about updating or not the software sprites position (or animation frame).. not just the enemy internal logic (that for me is irrelevant in processing time). In that case wouldn't it look a little strange if we don't update the sprite for a frame, but the screen scrolls in that frame (moving the software sprite with it)? If the screen didn't scroll also in that frame then all is good, but then we need them both in sync and maybe that was what you were implying..
  18. Sure!.. there is always the possibility that is done with the assets available x) Anyway, in my case it will end in the A8 instead of the 7800, but if you don't mind..
  19. The PM's are only the graphical representation of your player, internally the code assumes (is hard coded right now, if I remember correctly) that you are moving an object of 4x8 pixels (1 char). So you would need to update the size of the internal "collision" object through the code.. I would need to take a look for possible unknown problems, but at least change this code, in pro_P1.asm: ; set size in pixels ldx #4 stx m_playerSizeX dex stx m_playerSizeXMinusOne ldx #8 stx m_playerSizeY dex stx m_playerSizeYMinusOne jsr InitPlayerInfo ... Is not that simple anyway, because with a sprite so big you need to add more collision checks, to avoid going through small objects (the collision checks right now are done only in the corners of the player). You would understand if you try it The other solution is that your level doesn't use walls or platforms that are smaller than the player. Regards.
  20. Meat Boy 2600 style x) Hey, I think Bagman should have 2 votes
  21. The bit trip version looks perfect for the 2600 x) At least there is a lot of info out there, if someone wanted to replicate the movement "physics". http://meyermike.com/wp/?p=160 Demakes of http://supercratebox.com/
  22. A nice thing about this one is that the levels fit nicely in 40x25 char mode: Also with Turtles, this one is 28x28 (but you could live with 28x26 and a couple of scanlines to show the top and bottom limits) These mock ups are done with Envision PC, so they are already in antic 5 char mode, but maybe the colors are a little off. Another good thing of this type of games (and others, like Rally X for example), is that you could reuse code for movement, collision checking and font based rendering, because the enemies and the player live inside a char based grid (and you get the extra color). Yep, I implemented the movement of the player (walking, jumping, falling) and shooting bubbles. Probably my first experiment with software sprites. With the amount of moving elements this one have, I would say is a better fit for bitmap software sprites, but I have never done char based software sprites so.. I agree with you about Rygar, it would look more like a "demake", but I think that the gameplay could be similar and still fun. Try Jumpbug if you can.. is kind of crazy for how old it is The control is weird at first, but it makes sense at some point x)
  23. I was looking at the D9 version: http://www.2600-daptor.com/2600-daptor%20D9.htm Is that new? .. it looks like the final solution.
  24. Ha.. I was talking about something better than that (at least about the engine, that's no game yet). I found and old list of possible ports that I liked, all arcade games: Exerion Front Line Jumpbug Empire City Crazy Climber Bagman Sidepocket Turtles Road Fighter Starforce Raimais City Connection Elevator Action Rygar Bubble Bobble
×
×
  • Create New...