Jump to content

NRV

Members
  • Posts

    444
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by NRV

  1. So more people can see your pictures.. nice project!
  2. NRV

    Lunar Patrol

    I always liked Bubble Ghost in the Atari ST.. is great to have a version now for the 7800
  3. I believe the 7800 could do a pretty good version of the arcade one..
  4. Lol.. I can also recommend that one. But maybe a little too advanced for a pong game Nice game Vins!
  5. Yes, that one. https://strategywiki.org/wiki/Yuu_Maze http://gaming.moe/?tag=yuu-maze Sadly, it seems it was kind of bad.
  6. You could try to look for some kind of source code, or disassemble the original Z80 roms (from the arcade version), or maybe look at the 6502 NES version (not the exact same game, but maybe the enemies have similar behaviors). What I did was to look at a couple of youtube longplay videos and also played the original game in Mame, until I have an idea of the algorithms behind those behaviors. Sure, is not that simple with the more complex behaviors, but I wanted them to be good enough, not perfect. In fact I remember seen some videos where an enemy did something that I could not explain with my final models, but at that point it could even be a bug in the original code , so 99% was good enough for me. In the end you cannot really do it perfect without looking at the original code. After you have the basic behaviors in a nice list of steps and conditions you can start thinking about algorithms. This is going to be easier if you have experience with those. But for ""AI"" so simple as this, probably this list of steps is already your algorithm. Then implementing this in your chosen language will depend on how much experience you have with it. There is no shortcut for all this, you just start with simple things and move to the complex ones.. baby steps as they say (and time and patience). As an example, one of the behaviors for the first enemy is that it tries to rotate toward the player's "perpendicular" direction, every time that it gets to an intersection in the maze. Then if the enemy is moving up, and gets to an intersection or a front collision, the final code look more like this: .proc BehaviorUpFollowTarget // if there is a CounterClockwise exit and (playerX < enemyX) rotate CCW // if there is a Clockwise exit and (playerX >= enemyX) rotate CW // if there is no front collision continue front // else turn CW, CCW or back.. And there is equivalent code for when the enemy is moving right, left or down.
  7. In the old player you just change the code that writes to AUDCTL. I assume that it would be as easy to do in the new versions. Normally there is only one write to the hardware registers at the end of the RMT code. To implement APAC with IRQ's and play RMT music at the same time for example. I suppose the RMT player's code could have a generic "AND mask" and a generic "OR mask", so a user could clear or set specific AUDCTL bits. Don't know if that is what you need
  8. Probably is not Lady Bug, RallyX, Turtles or JumpBug, but I would be ok with any of those ? The other well known Z80 arcade conversion there... yeah it would be a challenge (but it would be really nice having your version in the A8).
  9. After all the experiments from Vinscool, Synthpopalooza and other people, I would say that supporting custom note tables (3) and providing fine control over all the Pokey values per frame (7), when needed, are the most important. You can forget about number 6. It was that sometimes, some note tables or instruments, need to be used in specific channels. But you can give total freedom to the user in the end, there is no need to check everything.
  10. I would try with something like: BASE = $5000 SETVEC = *-BASE BUFFLEN = *+1 ERRNUM org *+24 org *+49 .sb +128, " START " (untested!)
  11. You made me remember that I typed that one, almost finished it, but lost it to the Atari Basic's lock up bug (could not save it ?). Never tried again x) Probably the ones I played most: - Zurk: http://www.atarimania.com/game-atari-400-800-xl-xe-zurk_5952.html?version=5952 - Kooky's Quest: http://www.atarimania.com/game-atari-400-800-xl-xe-kooky-s-quest_2834.html?version=2834 - Avalanche: http://www.atarimania.com/game-atari-400-800-xl-xe-avalanche_442.html?version=442 - Spy Plane: http://www.atarimania.com/game-atari-400-800-xl-xe-spy-plane_4952.html?version=4952 Maybe Avalanche could interest you.. is a QBert clone in machine language, from Analog.
  12. There is already an A8 version of Raimais, so there is code done if you need it, but probably if there is a popular vote Bubble Bobble would win x) (and the graphics for the 7800 are already done in this thread: )
  13. https://en.wikipedia.org/wiki/Pac-Man_Vs
  14. Couldn't resist doing it with other colors of the A8 palette (Altirra default NTSC):
  15. As a general programming advice I prefer the other option, detecting the "just pressed" event, so a detection of a "key not pressed", followed by a detection of "key pressed". That way you know that no other application can mess with yours. Also, detecting "just pressed" feels more responsive than detecting "just released", from the user's perspective. But I understand that this doesn't protect you from messing with the next application
  16. What method do you use? When I did my pseudo clone I moved all balls by steps equal or lower than one pixel, many times per frame, checking if they cross over brick limits. With this there is no problem with the collisions (even if you hit more than one brick in the same frame), but the problem is that a higher speeds (and with more active balls) the processing cost is also higher. So I don't know if this method will work well with the 7800. Well.. probably there are ways to optimize this, like doing the fine steps only if we are moving through a zone with bricks on it.. but I never explored this solution.
  17. Is kind of funny that this can done almost equal (or better) in the A8 (G0, P/M's for the white "underlay" color, narrow playfield).. and the arcade uses a 6502 clocked at 756 KHz. How much do you like the original?
  18. Not that I'm participating, but I normally do two versions of my games NTSC and PAL.. would that be ok with the competition rules?
  19. Not trying to influence your opinion, I think both options are valid, but I just wanted to add a vote for some "mild" randomness. Probably one of the extreme examples for this is something like Spelunky (or Rogue Legacy for metroidvanias), and for sure that have some epic speed runs In my case, when I do any type of game I end testing it so much, that I feel forced to add some kind of randomization, so it still feels fun down the way. Without changing the order of rooms, I have experimented with changing the starting direction of the enemies, changing slightly the speed of some enemies and obstacles, adding a small random delay to the start of some periodic events, all with the intention that the player don't only memorize every pattern, but has to adapt to the small changes. Anyway, whatever you do is going to be a great game ? Saludos vecino.
  20. Ouch.. that fired some neurons that were sleeping for more than 30 years x) The vector line maze.. the sound.. It was in the Analog Compendium.
  21. If the macros provided by mads are not enough for your case you can do your own. But you need to decide first where you want to put the results (A, X or Y, or some memory addresses). Also if you want to support negative numbers and how you handle the cases where there is overflow (adding two bytes could give you a word result, for example). Anyway the syntax would be something like: .macro Add .if [:1 < 256] .and [:2 < 256] // code to add two bytes.. .elseif [:1 < 256] .and [:2 > 255] // code to add one byte and a word.. .elseif [:1 > 255] .and [:2 < 256] // code to add one word and a byte.. .else // code to add two words.. .endif .endm
  22. More than that, if you have more than one software sprite: - first "erase" all previous/old sprites in the screen - then draw all new sprites ..repeat Erasing means restoring the background and it can be done in different ways, for example: - if you background is empty, you just put 0's in the old sprite position. - or you could have a copy of the background in memory and just copy the area touched by the sprite from there. - or use some other logic to restore the background, like when using background "tiles".. Drawing can also be done in different ways, some of them faster but prone to more visual artifacts: - just storing the sprite data on the screen without masking or caring for the sprite "borders" against the background. - doing an OR or XOR/EOR of the sprite bytes against the background. - doing the "proper" method of having a sprite mask (different than the sprite data) to AND against the background (basically cutting a hole with the shape of the sprite in the background), and then ORing the sprite data against the background. Then there is the problem with rotating the sprite bits inside a byte, because the graphic modes use 8, 4 or 2 pixels per byte. This can be done in real time (slow) or having the rotations pre-calculated in memory (faster, but using a lot more memory). All this is for graphic modes. Char based software sprites are a little more complex.
  23. NRV

    Chess

    Nice page. I add a vote for the ideas in Really Bad Chess. It "seems" easy enough to implement and is a lot of fun to play x)
×
×
  • Create New...