Jump to content

NRV

Members
  • Content Count

    436
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by NRV

  1. Would be valid for you games that doesn't exist, but should? x) I would like to play things like: (and maybe program some of them) - a "Kick Off 2" type of game (sensible soccer.. what's that? ) - "Star Raiders Galaxies" (a modern sequel to the original, with good space combats) - "Montezuma's Revenge 2" (with a better title probably.. and some ideas from Spelunky) - a "Wonderboy" type of game (the arcade one, or the ones in the "Monsterland" series) - "Exed Exes XL" (an Atari version of the arcade one) - a good arcade racer, with a good frame rate and with hills (the engine/game that I have in mind doesn't have a good model) - a game in the "Galaga" family - "BallBlazer 2" with 4 player support, 2 per team (maybe connecting 2 Atari computers) - a "Super Mario" like game - a good pinball game also.. - a good first person game (only raycasting), with colorful graphics and over 30fps, with enemies, shooting but also puzzles.. maybe capturing some of the action that Encounter had.. + lots of others 2d games: Rally X, a good 2d golf like game, a PacMan like game (with new mazes, ghosts and abilities), a "Lunar's Lander" type of game (but with elements of "Gravity Crash" in the ps3).. Most of these are because I believe that a very good version can be done in the A8, with good graphics and very playable. I support Irgendwer in trying to do "new" things, but I understand that the probability of that happening is lower than straight ports, if we are doing this just for hobby.. Maybe a compromise and ask for "new levels" in the "not so straight" ports?
  2. Offtopic.. yeah, nice game there Pretty good samples and animations.. and I suppose that's the c64 high resolution mode?, it would be difficult to have the same clean look in the A8 (or a lot of work using pm's underlays). I "LOLed" at the alien x) @Antonio, have you published info about your ball physics and collisions code?.. it would make for a nice article. Sometimes I think about doing something like "Super Stickman Golf" or "Desert Golfing" in the A8.
  3. Nice.. The rhythm and some of the instruments remember me a little of the Wings of Death music (or was it Lethal Xcess?).
  4. Greater than perfect conversion guys.. Annoying question for all involved.. sorry to ask x) .. If this could be "easily" converted to use gr.7 like graphics (or the equivalent char mode), how much do you think that would improve the frame rate? I would hope for something near 12 fps.. like 1.5x faster. Regards!
  5. Nice.. so when do we expect a working test? x) Also, why 240 lines? .. I suppose it should work for any number of lines? And how would using narrow mode (128 pixels) help you to achieve this? Is possible to still use pm's? Regards.
  6. You also need to change the charset every couple of lines probably.. But not having cycles available in the bad lines doesn't prevent you from changing the graphics anywhere, or using this for a game.. I don't follow your logic here. Obviously, if doing a game I would try to use one IRQ every two lines (not one big DLI over the whole screen), but I need to test if this works well changing 4 registers.
  7. Yes, but (normally) you would have the same restriction of selecting the new color for all the character. I would use it as a new color in the "hue" lines and would leave the same 4 values for the "luma" lines (set PF3 equal to PF2 there), so that you get 20 colors instead of 16. I think you can change the use of PF3 per line, but I don't remember how that works. Also using chars can complicate the timing to use DLI's (or IRQ's) but it should be doable.
  8. Remember that you could also use IRQ's if you want to sync some changes to a specific horizontal position. It's not perfect (there is some jitter, according to what instruction was interrupted), you lose one audio channel (well, you can use it for samples..), but you can avoid stalling the cpu for some cycles.
  9. Aaaand.. couldn't resist doing a couple more.. this is kind of relaxing, like a coloring book x) house.xex wario.xex Altirra's palette, pal, pal blending.. hope they look good in a real tv. Both pictures have one color (hue) change for the last 32 scan lines (and that simple change gets you 4 new colors). All players are free, so you can still add a lot of color if you really need it. Should do this with irq's, but didn't have the time.. Regards.
  10. Don't know if your converter or what, but your version seems to miss the darker reds and some of the greens. I did a fast version also, it should look more like this: screen.xex Also, I suppose using the pal palette from altirra is not that correct for this conversions, because the final image seems to have half the saturation.
  11. Couldn't resist doing a small picture using gameboy tiles, colored by hand. I added some code to the script to modify a picture to show what you would see in pal emulation, but packing the pixels for 2bits per color would be pretty simple. Original: (Altirra's palette, 128 pixels wide) With color + luma lines (with pal artifacting):
  12. Luma 0 or luma 2 (joystick up), plus scanline jitter (joystick button), plus altirra pal, fullscreen, pal artifacting and frame blending --> perfect! x) Maybe frame blending is kind of cheating (unless you have a "modern" tv that do it for you.. whenever you like it or not), but is difficult to get the "correct" screen interlace look in emulation. If you were to do a game would you try using irq's instead of fullscreen dli's? (and maybe narrow mode). What do you mean with color mapping? re paletizing to your 16 (?) colors? I recently did code to re-palettize (c#, unity) a png using a 256 color palette and also to compress (shrink) images to different zoom levels. Don't know if that would help. I was using Imagemagick before, but I wanted more control about what colors you get when you shrink an image, and you start blending a lot of pixels into one..
  13. What? (anyway that would have been Miker ) (Lol.. I just now saw the video) That's the second floor of P.M 2.0..it was a quick a hack to the renderer, but is still rendering (monochrome) textures, so it could run a loooot faster than 20 fps, if done correctly.
  14. Without looking at the code, sounds like you need to use another key for unpause (like esc), instead of space..
  15. Alternate Reality the Dungeon, with the FBI agents and the "long arm of the law".. but that wasn't "subtle" x) Gods in the atariST did that, for all the levels before the first boss, that I think was inmortal. The only problem was that, when I played a good "backup", I was disappointed about the real difficulty of the game.. the bad copy was much more challenging
  16. Nice. The "infinite" jump is in the code, but commented, the "wall grab/slide" should be easy to do, and something like the big wheels could be done easily by animating chars in the font (but maybe using 2, 3 or 4 fonts interleaved in the screen). I believe one of my inspirations at that point of time, was something like star guard: Also doing something with a fraction of the options in n++ (and a little less hardcore), would be nice.. kind of a modern lode runner.
  17. Yes, I disabled them (commented the code) for later versions, because they are big pre-compiled sprites, so they took too much memory. But when all is running from a 1MB cartridge, then I can reactivate them and they should just work. I think I have said this before, but.. at 40 fps both barrels in screen took like a 10fps hit, so the current engine should run near 15 or more fps, with both of them. Obviously there is more work to be done, apart from the rendering. Basically calculating when to render an object, in what direction (camera angle vs object angle), at what zoom level (distance to the camera), doing the clipping against the walls (comparing "z" values). But if the ideas I have in mind work well enough, then this extra cost should be small compared to the rendering one.
  18. It makes me think also in Adventure 3.. if Adventure were a platform game Yes! .. in fact I learned it from you, when looking at your example code to create a 1MB cartridge, directly from a mads source. I used .proc a lot when moving the projectM presentation to use a cartridge, but this one here is very old code. Another thing very useful when using .proc, was the option to set a specific assembly address, for when you need to move your code from the cartridge to normal ram.
  19. Hi, for the people that is still interested in this.. x) As you know, it has not advanced much these last years, but recently I had some time to look at it again, and did some actualizations. I started moving the presentation code to use a 1MB cartridge. A big step for me, because I never did it before.. thanks to JaC for his code example, in some part of this forum . Now it would be easier to move the rest of the code and add more things. Also I used another of the great musics from Miker: I did some small optimizations to the main code, recovered the rotation pivot in the camera (smoother rotations) and changed the camera fov (field of view), so the walls look "bigger" and more detailed now.With this I also added some graphic "quirks" that I need to fix, mostly when you are too close to a wall. I don't know if you can see all that in the video, but I think it looks better: There is another video in my channel, but is from the first version of the PM demo (the render engine test with the barrels). Regards!
  20. Hi, this a platform game engine that I did mostly in 2010. Recently I added the enemy logic, the laser barriers animation and some other details. I hope people can find it useful to look at the code, or maybe use it as the basis for a game. What I implemented is a system a little more complex than what you normally see in the A8. Most movements have a different speed and acceleration defined, and some of these values use fixed point math. For example you can define the speed for walking, jumping, falling, swimming, climbing, and the accelerations used to reach those values. Also you can hold the jump input for higher jumps and use some air control. Right now you shoot with the button and jump moving the joystick up. I don't like this much, but I wanted to test having both options for this prototype. I normally play in a pc using the keyboard, so maybe the values are a little too sensitive for a real joystick. There is a PAL version, but is a little different than the NTSC one. I did translate the speed and acceleration values, but it seems applying them 50 times per second has not the same accumulated effect, that at 60 fps (it feels more "floaty"). Also, there is a precision problem trying to translate the smaller values (should use more bytes). Here, a video: The engine is pretty efficient, most of the time in the frame is free as you can see here: For example, the enemy logic only updates one enemy per frame, looking if the player is near and then shooting in the correct direction (if the cooldown and the number of enemy missiles allows it). Other details: - Most collisions tests are char based and assume a player with the current size, but they can be changed for bigger players. Only the collision between the player (P0) and any danger, use the hardware registers. - The player logic use a system of states to know how to move and what collisions to check (over platform, jumping, falling, climbing and in water). The color of the player changes according to the state and also to what he hits, but this was for debugging. - The camera speed is based on the distance to the player, so is smoothed out a little. - Most objects coordinates in the level use 2 bytes and are translated to screen coordinates before rendering. With a moving camera you need to update your player/missile graphics, not only when they move, but also when the camera does it. The level was done in Envision PC (the "reborn" version) and is easy to modify, but there is not much error checking, so beware. Code was done in mads and tested in Altirra, as always. The condition to "win" this demo is collecting all coins and destroying all enemies (the clock stops then). My record for this is 1:16.1 in NTSC, but I died once open_plat.zip
  21. xbios? https://atariwiki.org/wiki/Wiki.jsp?page=XBIOS
  22. Yep you should.. Off topic: I tried to answer your question, but it seems your messenger is full.
  23. Let's say you implement a game in graphic mode 7, with a window of 128 x 64 pixels (just throwing numbers). Every line uses 32 bytes of memory (narrow mode playfield), and lets say your video memory starts at $8000. Using unrolled code you could have 8 methods like this: sta $8000,x sta $8001,x sta $8002,x ... sta $801f,x rts (97 bytes x8 = 776 bytes for all methods) This one covers the case for the first 8 lines, if you want to write in line 0 you set x = 0, for line 1 you set x = $20, for line 8 you call the next method with x = 0, and so on. For filling one line then you basically need to set the accumulator with your "color", set x with the line offset, jump to the correct "sta", and write a "rts" at the exit point (and recover the original "sta" at the end). Also this is for filling 4 pixels at a time, you still need to set correctly the "borders", so probably this is better used for "lines" larger than a fixed value (if the setup is to costly). But your throughput would be something like 1.25 machine cycle per pixel. .. or you could remove the use of "x", write the methods for all lines (using 776x8 = 6208 bytes), and get 1 machine cycle per pixel..
  24. The performance analyzer is really nice, thanks! The slightly grey area is something like the vblank? It would be nice, at some point, to be able to use the source listing (in mads) to set colors for specific methods and maybe have some kind of visual marker for when the logic frame really ends (or could be done automatically, but it seems there are many methods to change to the next frame, like changing the DL address, changing the DL jump or LMS instructions..). But probably you have something better in mind.
×
×
  • Create New...