Jump to content

MemberAtarian

Members
  • Content Count

    388
  • Joined

  • Last visited

Posts posted by MemberAtarian


  1. Yes really...

     

    http://www.thelogbook.com/phosphor/odyssey2/trackball/

     

    I think the O2 joystick, with its range of motion, is far superior to the CX40 for open field games like killer bees (though you could argue the CX40 was better for left right shooters).

    There are some games that are better with CX40, like Hero, Thrust+, Super Cobra Arcade, but as you said, I mostly use a Sega Master System controller.


  2. Big Odyssey 2 fan here... Excited about this project, but will it play with a trackball? The Odyssey 2 game actually worked with the super rare O2 trackball...

    Really? :o I always played it with the joystick. Odyssey has really bad joystick though.

    I don't know if there is a way to make Batari Basic use the trackball. I know there is an asm include for keypads and paddle, but to be hones, most people only own the joysticks.


  3. Hi guys, I begann with my new game and finished the really detailed intro (it tooks up early one bank :D ), but I have a problem right now. I use Batari Basic and a little bit of assembly.
    Because I really will need space, I changed the original rutine for music, so of the volume is set to null, it won't read AUDF and AUDC, a lot of space the spare. :)
    But here is my problem: In the intro, PF0 is set to %00000000, because the sky looks that way better as the girl is falling. In the actual game I set it to %11111111 to create walls on both sides. Because I really hate color dismatch, I sacrificed p variable for background colour, before every drawscreen there is a COLUBK=p line, then I want to change the background color to black at the end of the screen, and in the vblank, I change it back to "p".
    So, the problem is, if I put this line:
    lda $00
    sta WSYNC
    sta COLUBK
    Only in the playerscores.asm, there will be a huge gap between the playfield and the scoreboard, and that is really ugly. So I thought I will search for a better way, modifying the std_kernel. I found out if I put the line above in the endkernel, before
    stx PF1
    stx PF2
    stx PF0
    The gap will disappear, but the last line of the playfield will be the standard mirrored playfield on the left side. Without WSYNC, the gap remains at the left edge (where the PF0 sets the wall) and there will be a little flicker of the pf color if the pf is scrolled.
    So basically I would like to make the 12th invisible hline of the playfield black. Any ideas? :)

    I tried to use CTRLPF, but it does nothing. I heard about something called oldscore mode that allows you to draw a nonmirrored playfield, but I did not find anything.

    post-43241-0-08399400-1527401627_thumb.png

    post-43241-0-91250600-1527401636_thumb.png


  4. 1. I do it with this rutin:

    if player0x>player1x then temp1=player0x-player1x else temp1=player1x-player0x

    if temp1<10 then "collision"

    I will try to do it with your ideas, I have a lot of time for that right now. :D

    2. The problem is that this is not assembly, so I have p1-p5 for all the enemies. p1-p4 are the people and the tombstones, while the 3 swarms share p5. n{0} and n{1} creates a three turn based drawning, as with !n{0} p0 is your swarm, with n{0} and !n{1} it's the left cannon and with n{1} it's the right cannon. So with this, you would NEVER collide with swarm 2 or 3, so I used the rutine I mentioned above. And because you can see every swarm in every third turn, and p1, p2, p3, p4 and p5 are basically all p1, mostly the swarms disappeared for sight, so if p1, p2, p3 or p4 shares the same line as p5, p5 is always above, so the person player go to y position 160 if they met.

    3. That is the only part that is not included in the original game. :D I will see if I could make the space bigger, I really hated creating the pf in multisprite kernel.



  5. I fixed some bugs (LOL) with placement and collsisions (the collisions are not using the rutine of the VCS, but cheching difference of variables), but more important, I created a logic to reduce flicker of enemy swarms, basically if an enemy swarm is at the same position as a person or grave, their y coordinate becomes 160, so they disappear and the TIA can draw the swarm. So I can draw 7 sprites by placing p1 sprite.






    I will start developing the last stage, it will be epic. :) End of course, I have another homebrew idea in my had, inspired by an anime I saw 10 years ago.







    • Like 1

  6. I'm not familiar with the O2 game so have no idea what is happening in the video. Do you have a manual planned?

    I had not learned how to use Krita and Inkscape this year for nothing. :D

     

    You are a swarm of bees and killing people. In the original game they are more like aliens, but I think killing humans is more satisfying. :D There is a lazer cannon pair at the edges of the stage, they are charged after a short time. (in this case, the counter goes up to 255), they are following your y coordinate, so you can eliminate anyone who's on the same "scanline" as you. The enemy swarms can be only killed that way. I don't really remember if there were more behavior of the swarms, in my game, there are two kind, the red is easy to avoid, but the blue is following you.

    Interestingly, the Videopac is weaker in many aspects, than the VCS, but it can handle more sprites (4 unique, 12 prebuilt and 4 quad in a line) and have an additional 64 bytes in the CPU, added to the 128 bytes video/audio RAM.


  7. There will be a lot to do, but at least it starts to look like the game I want. The biggest problem is the collision, as you and the cannons are created from p0 sprite, the 3 enemy swarms are made by sprite5, a pseudo sprite of player1 in multisprite kernel of Batari Basic moved across the screen. The other hard part is optimizing, I end up with 263-267 circles as I touch something.

     

    I made my own rules, the enemy swarms respawns till there are people left. The people have the same AI as the scientist had in Apollyon, they try to avoid you as you got closer. There are two kind of swarms, red is just wandering around, blue is following you.

     

    What awaits you on stage 6? Let it remain a mystery. :)

     

    Beeware_NTSC_0.08.bas.bin


  8. 2018.09.09.:

     

    A little update:

    • Changed colors of red swarms
    • Optimized code, so it won't flicker with PF color on real hardware
    • Added an endless mode. After you beat the boss, press fire or reset on the end screen, that will give you a stage like the 5th one, but you can only kill the people temporary.

     

    Although it seems right now impossible to cover Utopia for the Atari 2600 in Batari Basic, I found a way to learn using the multisprite kernel, so I'm gonna create my favorite Videopac game for my favorite console, so I can play with it without buying a Videopac again. :D

     

     

    Beeware will be much like the original, controlling a swarm of killing bees and killing people. :D You have to avoid swarm of enemy bees, but you can kill them with your charged laser. Of course, I will add some elements to the original. :)

     

    You can watch Killer Bees here, if you are not familiar with it:

    Beeware_NTSC_0.08.bas.bin

    Beeware_NTSC_0.24.bas.bin

    Beeware_PAL_0.24.bas.bin

    Beeware_PAL60_0.24.bas.bin

    Beeware_NTSC_0.25.bas.bin

    Beeware_PAL60_0.25.bas.bin

    Beeware_NTSC_0.28.bas.bin

    Beeware_PAL60_0.28.bas.bin

    • Like 5

  9. My problem is the same as mentioned above, the only thing that is in my way that I would write the very first (?) strategy game for the system, but I can't do it, because I have to choose between having 5 sprites in multisprite kernel without showing resourches (which is important in an TBS or RTS), or doing this crazy movement of player1 sprite, even using player0 for filing, but still, the flicker kills your eyes.

     


  10. 1. During you actual turn, you can only see your own island (and the oil on the sea), so there are only 15 sprite drawn maximum, instead of 27
    2. Every time there are doubles in a row, the program detects it and does NUSIZ to make more sprites appear at the same time.
    3. Every time NUSIZ was used, as a sprite would be drawn that was already drawn by NUSIZ, it is skipped, to reduce the number of turns and flicker.
    4. On every second turn, the cursor is used to draw the sprite that was draw in the prevoius turn, so it seems like more solid.
    But this is the point I don't really any have new ideas to reduce the flicker. I tried to adapt it for multisprite kernel, but as I try to make a playfield, it always crashes and reboots the system. Any ideas?

  11. 1. The console you like.

    2. If you want to get the girls, try the Atari 2600, it's the hardest among the popular machines if you are using assembly. Just joking, but, if you like challenge and fighting the limits the console have, even with Batari Basic, you can create great games. This is the kind of system that is not about the time you invest in coding, but your abilities ang logic.

    3. If you want to do detailed games with hard work, choose the Dreamcast. It eats pirate copies without modding and has really cool abilities.

    4. If you want to reach most people, Commodore64, Gameboy or NES

    5. If you want to make copies easily, Commodore 64 (casette or floppy) or ZX Spectrum.

    6. If you are crazy as hell, try the Entex Adventure Vision. :D



  12. It's far from perfect, but it at least works. The buildings are created via replacing the p1 sprite. If there is no object at the area, it will jump for the next area, so if there are less object, the flicker is endurable, I managed to fit it into 262 scanlines.
    My next work will be refining it, so if there are ones from the same in a row, I will use NUSIZ to save the day.

  13.  

    Maybe not,

     

    "Dis-" is a Latin prefix, "dys-" is Greek.

     

    Webster's says "dys-" means "ill" or "bad." "Dis-" means "apart, asunder, away, utterly."

     

    Also, the "-topia" in "Utopia" comes from the Greek for "place."

     

    Given all that, "dystopia," would mean a "bad place" and "distopia" would mean a place torn apart.

     

    I have seen the word distopia used in older books but it seems to have disappeared for the most part. It could also be a regional thing.

    In my mothertongue, it's "Disztópia", so we use the older way, but I have corrected it in the code.

×
×
  • Create New...