Jump to content

NRV

Members
  • Content Count

    436
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by NRV

  1. No, version 1 already used the IRQ timers.. probably is something small, like the differences with the display list that Miker corrected in his version, so it worked again in Atari800WinPlus. That version should do it.
  2. (offtopic) I have not checked the site in the last years, could be more updates.. (he was trying to implement the Galaga code in C). http://pushpopmov.blogspot.cl/2012/08/galaga-z80-disassembly-uploaded.html General info: http://galaga.info/ Some of the interesting links seems to be dead, like this one.. maybe in the wayback machine. http://www.computerarcheology.com/wiki/wiki/Arcade/Galaga oh.. but this works, nice (code with comments.. also check the info about the sound of Time Pilot ) http://www.computerarcheology.com/Arcade/Galaga/ more code info: http://donhodges.com/galaga_stage_256_fix.htm I did have a backup of some source.. z80.zip
  3. Nice! .. so basically IRQ's are the "future"? x) Probably I'm going to look at your source to see if I was doing it right all this time.. Edit: Yep it looks similar. From what I see you have two irq's (IRQ and IRQ2), for odd and even frames, one dli (dli0) at the start of the frame (I suppose), to init stimer and irqen, and one vbi. Also you use the same trick of one irq every two scanlines (this seems to be the fastest way, but needs to burn some cycles in the middle..is that what you do with "#cycle #13"? .. is that Mads?). The only differences with my code is that I never use a vbi (I deactivate them and just put a dli there, if I need one at the bottom of the screen), to simplify the NMI handler. Also I only set stimer one time, at the start of a program (not every frame), but my horizontal sync looks more complex because I need to burn some cycles (after calling two "sta wsync" in a row), so the first irq is always called at the same horizontal position (in the scan line).
  4. I forgot to mention that, for the next step, I need to reorder the code and start using the banks in the 8Mbit maxflash cart. But I don't know much about cartridges in general. My idea would be (if possible) to generate an Altirra maxflash cartridge, directly from Mads. For that I need to be able to assemble different code with the same address (the 8k bank/window), and also generate any kind of header and checksum info that is necessary. In my case the first thing I do is deactivating the operative system and using all the memory, so no need to follow the OS guidelines I suppose. So anyone that can put the simplest code to do this (or a link to the info), would be of great help. I believe it should be possible, but normally I have seen people using external tools to generate the final cartridge code. Related pictures: http://www.indiedb.com/games/starshock Related videos: Related game: (to farm for ideas x) ) http://phoboslab.org/xibalba/ Regards.
  5. Warning, long post ahead That video looks pretty smooth, inclusive when reaching one digit frame rates. I suppose that's and advantage of the resolution and being monochrome. I think I read something about the techniques he used (in a link from FormatWars maybe?). Doing some kind of eor filler, with raycasting only for the limits between tiles, but I could be wrong. Anyway, doesn't look like I can reuse those ideas in ProjectM, maybe the raycasting one, but I already have one good optimization to implement there (that involves doing it with a binary search, to at least interpolate the final height of a row in between). Yep, I also prefer the 256 color mode, and wouldn't change it a this point. What I miss right now is the true two pixel per byte resolution in GTIA. Probably I will try to do it just in GTIA9 in that case and just reduce the number of rows. I wouldn't like to use any external hardware acceleration for this, but I find it interesting that just doubling the cpu MHz in Altirra (65C816, 3.58Mhz), almost get the frame rate to 50. I don't know if the IRQ's are taking time in that case (because they look broken), but is a good scaling. Yes, that's another good thing in that demo. I don't have areas that "open" in ProjectM, precisely to control that. You could set the limit as an option in a menu, so the user decides, but there is no point in searching for a collision beyond the minimum height of a wall. Good thing if you have a game with limited visibility, like a dungeon, where you only see black/darkness beyond a certain distance (or some kind of fog.. GTIA9 again, hint, hint). From the graphic side I would choose doing them just in the same mode, like the barrels in the first demo: http://www.atariage.com/forums/topic/148697-project-m-stage-1/ Direct conversion: Hand made, first version: Hand made, final version: I did some graphics tests using Player/Missiles.. original one: My version with a couple of line color changes: But it takes too much time for me to do something like this (I'm not an artist x) ). I would prefer to use the P/M for small projectiles and shot effects, maybe for the main weapon or other overlaping static effects. The two barrels in the first demo (precompiled sprites), have a load of like 5fps in a 20fps system, approx. So if I were to put them in the current ProjectM, I would get frame rates between 15 and 20 probably. From other thread: I have already decided in using the 8Mbit cart. It's just more memory and would allow me to do everything I want (more wall variations, pre compiled sprites, animations, recovering the smooth rotation from PM 1.5 .. go take a look if you don't remember). No need for hardware assisted DMA or other things, but the code could adapt and give you a better frame rate if you have a better cpu. Nah ... I have seem this from time to time, and my answer is still the same. I don't have much time these days (for the last years I should say). Also I'm not good working just a little everyday, so is not technical problems that have stalled this. In fact, I don't see any major problem ahead. Neither sprites, collision detection or AI are great problems. - Clipping: for precompiled sprites you can reorder the code in "sprite rows", then clipping a row is just comparing the current sprite distance to the camera with the distance in the world "row Zbuffer", and then starting (or ending) the draw at the correct row. For P/M's it would work in a similar way and at the end just setting a mask, used to draw the P/M. - Collision detection, AI: is basically a 2d top down world. First, I don't think you need to have that many objects active locally. For projectiles is basically a couple of X/Y comparations, or tile comparations (against walls for example). For enemies you don't need to start doing A* for this to be fun . Lot of "2d games" (like PacMan, Robotron, Eidolon, Encounter) have ideas that can be used to move enemies and get interesting behaviors. - Sprite scaling: here you don't need to have scaling code. You could use some scaled frames in memory (not all sizes) and still have a good effect (like in Space Harrier). Eidolon don't do any scaling for example. Also, in the Spectrum demo the sprites appear and disappear at certain distances, and it still looks good. There are still more optimizations and tricks that can be used, to improve speed and visuals. Hiding sprites background (not drawing the world in the same rows). I don't like this, but could be an option for the user to decide. There was a recent Spectrum demo of an rpg with a 3d view here, that I don't remember the name, but the interesting thing was that they never did "scale down" of the graphics, only scale ups. So you don't see the typical artifactings in the walls, at certain distances or while moving. That's an idea that I would like to test to improve visual fidelity, for example. Regards.
  6. Short answer: get last version of the Altirra emulator, run it, unzip the ProjectM file, drag and drop the PAL file over the Altirra emulator (configured for PAL, with 64K and PAL blending activated).. should work.
  7. Yep, +1 to Rybags answer. I do that in my Pad game for the movement of the balls, enemies and powerups, and with different movement values for NTSC and PAL (so they move at the same "speed"). The only problem could be that for small objects it probably looks better (unnoticed) than for the whole screen (your case). But is by far the more elegant solution, forget all those if/then and counters.. just add two values every frame and update the scrolling/LMS's with the processed result. For example, let's say that you move one scanline every frame in PAL, then your two values are 1 and 0 (decimal part). Then you have a speed of 50 scanlines per second in PAL. To replicate that speed in NTSC you need to move every frame a value equal to 50/60 (50 scanlines in one second or 60 NTSC frames). So 0.83333 scanlines per frame, and your two values should be 0 and 213 (approx... is never going to be perfect for all cases with this method, but good enough). (What I did was to take the decimal part ".83333" and multiply it by 256 to get a new "byte" from it.) Obviously, you need to remember (accumulate) this 2-byte result from frame to frame. Also you can now do some kind of smooth acceleration effects, no need to have just 6 different speeds.
  8. I don't understand every little detail about IRQ's (for that probably you need to talk with Phaeron x) ), but from my own experience they could be faster. I normally trigger them inside a DLI once per frame, then they run automatically (as FJC says) over the scan lines that I need them, and then are deactivated for the rest of the frame (using a counter inside the IRQ code, or maybe using another DLI). You also need to do some kind of sync at the start of your code, if you want the IRQ's to happen before a specific vertical position (for color changes for example, if you are going to have one per scan line). The bigger issue is probably the lost of a sound channel. Emmm.. doing a WSYNC or NOPs is the same.. just lost processor time
  9. I did put the code of my last game here: http://atariage.com/forums/topic/191864-pad-15-beta/page-3?do=findComment&comment=2897188 (but this was started like 20 years ago, so there are like two programming styles coexisting here x) ) Some old demos with code: http://www.atariage.com/forums/topic/108283-more-software-sprites/ http://www.atariage.com/forums/topic/119962-why-are-my-shape-tables-flickering/page__view__findpost__p__1453933 http://www.atariage.com/forums/topic/52701-bubble-bobble/page__view__findpost__p__1260463 I would say similar to Phaeron.. with lots of comments, starting with memory maps, vars and constants definitions, then the inclusion of some standard equates and macros files, code initialization (for games something like InitSystem, InitGame, InitLevel), a short main loop with some jsr calls (read input, game logic, draw screen, screen sync..), ending with interruptions and data areas and tables (P/M's, fonts, DL's..). Also when the programs grows, logic groups of methods or data end in their own files.
  10. bcc --> jmp if (A < M) A = 200 M = 0 ..don't jump.. bcs --> jump if (A >= M)
  11. Nice. IMHO the last version is the only one that I find similar to the original tune.. I can kind of "recognize" it there.. The others sound just too different (at least for my tastes). So.. maybe increasing it to 400hz? (or adding other AUDCTL modes?) I vote for "there is potential left" x)
  12. I believe if you could increase the quality by using more updates per frame (4, 8..) it could be very interesting. Something like a rastaconverter but for sounds and music..
  13. I follow the same rule (and do the opposite when going from NTSC to PAL). Some colors are not the same (you can notice the difference) but as an overall change I think is the better solution.. Some examples: (NTSC / PAL , Altirra palettes)
  14. I remember some nice articles about the Synapse adventures: http://www.atarimania.com/game-atari-400-800-xl-xe-essex_1879.html http://www.atarimania.com/game-atari-400-800-xl-xe-mindwheel_3404.html http://www.atarimania.com/game-atari-400-800-xl-xe-brimstone_793.html But I don't know if they are at the level of the Infocom ones. The manuals looks nice anyways (and you need them for the password protection).
  15. Sadly no.. (well, very minor). Good to see you here by the way.
  16. NRV

    ;)

    "I herd him talking to his solicitor this morning" ... this one is wrong in SO many levels... I think this is now my "favorite phrase for crazy threads" here.. (make space you "envious snake"). What have you done flashjazzcat.. what have you done. That should be some kind of record x) I always knew you were evil flashjazzcat, showing only glimpses of your amazing project, year after year, without an exe.. (like I'm one to talk...) Yes.. I'm torn between doing a pc version in Unity, GameMaker or plain C plus OpenGL, with procedural levels, a kind of 3d infinite runner with elements of elektra glide, encounter, stunt car racer, stealth (landscape).. plain but colorful graphics with good gameplay.. Or doing the worst possible version, in a "satire" kind of way (I think this is going to be the most difficult.. the original material doesn't leave much room to make it worse). If only I have the time x) I can see this inspiring a global game jam with Peter Molydeux and Notch... Oh .. it was a trap from some devious lawyers all the time, and we took the bait
  17. Just for some great moments: - BallBlazer: beating the level 10 AI and many close matches with friends (replaced years later with Kick Off 2), the goals from midfield at the start of a match (there is a trick for that), the advanced techniques like hitting another player pursuing you with your own rotofoil (after shooting the ball) and one shot toward the goal that hit the left "wall", rebounded in the other player, in the wall again and finally entered the goal x) - Ultima 3: discovering Ambrosia and listening to that music for the first time, the secret walls (Ultima 4 was a more complete game, but I missed the music). - Alternate Reality The City: seeing that intro and the music for the first time (with lyrics), all the ambiance and mystery in the city, the rain and the small dragons (yep The Dungeon has a lot more things to do, with puzzles and quests, but The City has the advantage of been first and the details, thanks to the hand of P. Price). - Encounter: the many types of enemies, like the saucer that covered the field in shots or those annoying turrets, liked the clean and fast graphics, trying to reach the last level, trying to evade the incoming missile, hitting a pillar at the last moment but still destroying the missile at point blank ("RoF alien" stress level I should say x) ). - The Eidolon: not a lot of different things to do (maybe discovering the uses for the energy balls and some small puzzles), but great ambiance and enemies, technically great, big enemies with good animation, probably one of the best "boss" fights in the A8 (not that great a finale) and the musical heads . Special mention to the other two, Rescue on Fractalus and Koronis Rift. Special mention for two players: One on One, Int. Karate, Archon and Mig Alley Ace. Also Star Riders, Pitfall 2 and Pastfinder.
  18. I believe that is because you can only mix the color of the missiles (acting as the fith player, so using the same color) against the gtia 9 luminances. So you can have something like this: The 4 red and green zones are the missiles at 4x width (you can cover only that small area). Sure, you could replicate the missiles and change their color with midline changes, but that takes a lot of time. Well, with this I fall in the camp of non believers I suppose, because that looks like something with flickering, but with the flicker hide in some way (I'm assuming that this is a mode that could be used for gameplay, not just an static screen.. we have seen incredible pictures with RastaConverter already). The only proof for me would be one of those pics in a file so everybody can test it in Altirra (or someone that we can absolutely trust, like Phaeron for example ) As much as I would like this to be true (a new mode that no one has ever seen), the idea that the flicker was hidden on purpose and the secretiveness behind this graphic mode (when the important thing should be the game), doesn't paint a nice picture in my mind.. please, prove me wrong x)
  19. "For now.." x) I only can say that if is blending colors is going to flicker "a lot".. If Apac, I don't see the scanlines (but the "screenshots" look a little dark, so I suppose is one of these two).. Color changes inside the scanline are good mostly for title screens, so .. what else is out there? How do you know? x)
  20. The rule to avoid continue playing forever is very easy to implement. When you remove a color from the playfield, it is not generated again in your queue (and it is removed from your queue if is already there), this is what most Bust A Move games do (and also others like Zuma).
  21. He is probably going to write one for his needs. I have taught about writing something like that in the past, but never did (maybe Sheddy have some tools written for Space Harrier). Like Rybags said the code for pre compiled sprites tend to be specific to the code used to draw the sprites, but I also believe that something more generic and useful could be done. For me I would like to support parameters like X/Y resolution, pixels per byte, size of every line in bytes, offset between lines (or maybe a table, to be able to use any type of exotic format created in the display list), support for APAC (maybe interlaced modes), support for character based display modes (I don't want to start thinking about this , it would be more complex), be able to generate the color data and the mask for the sprite (if needed), different write modes (overwrite, xor, or, masked), use of optimizations (like don't write full transparent bytes and just overwrite full bytes that don't need masking), be able to choose if the draw routine wants to write the "pixels" horizontally or vertically (probably one version can be faster or shorter, if you have more repeated bytes in one direction), maybe be able to choose the level of pre compiling that we need (I would go for full speed, but sometimes shorter versions, that use less memory, could be useful)..
  22. Yep, he doesn't have much time this days, but I believe he is always lurking somewhere near x) (Timeline for reference..) http://www.atariage.com/forums/topic/148697-project-m-stage-1/ http://www.atariage.com/forums/topic/152979-pm-1-5/ http://www.atariage.com/forums/topic/174274-project-m-20/
  23. Yep, what he said, the first four options are for mouse controllers (Atari ST and Amiga) in port 1 or 2, the next four are for Atari paddles. I have not used Atari800Win for a long time, but it should work.
  24. Whoops.. I saw the same behavior in Altirra, but assumed that I didn't configured correctly the paddles in the emulator.. I will look at it. And here it is again, sorry x) padV2.asm I forgot to add the init for a couple of self modifying addresses, that included the use of the correct pot and paddle trigger (now it works in Altirra). Normally the init is done when you change the control from mouse to the first paddle option.
  25. Good to now that it works well and people like it Yep, that bothered me at some point also.. one problem right now is that maybe the game font don't have space for the 6 digits of a normal score (but I could add another font via a DLI if that's the case). Other problem is one of visibility, maybe it should be located inside the game area, because the screen is to tall and the top border is at the limit of a normal TV. I think I would try to add this at least as a toggle-able option, so people can decide if they want it or not and maybe cycle it through some positions. I did the changes for you in this file: padV2.asm (replace the normal pad.asm file) Basically changing the init of some vars: lda #4 sta m_selectedControllerIndex lda #128 sta m_usePaddleControllerFlag ... lda #1 ; 50% sta m_selectedPaddleAngleIndex And a pointer in one of the lines at "DL2_address", and the content of two lines at "DL2_options_line". Should be more simple, but I never did the correct thing, that the initial state of the title screen is initialized from the state of those vars, so you need to change both (yep, bad programmer). Also, you need to un-comment the line: ;PAL_VERSION = 1 ..if you want to compile and get the pal version of the executable. I'm not sure if a trackball works with the Atari or Amiga mouse settings, if not it should not be that difficult to add support for it. Anyway, the use of some keys or a joystick should be very easy to add and is left to the user as an exercise in programming x) I always resisted that option because it would be very difficult to have a good control of the pad and enjoy the game at the higher levels, probably would need some changes in the gameplay area.. is like moving a mouse pointer with the keyboard, not that fun Regards.
×
×
  • Create New...