Jump to content
IGNORED

Plague (Atari 2600)


MemberAtarian

Recommended Posts

I was amazed as well, but Stella does not play the older version it used to play correctly after I updated the title screen. (if you compile, it inserts the most up to date titlescreen.asm.

 

 

Hi, how did you count the scanlines? :D I only use Batari Basic, so I don't know how to make the scanline numbers correct, I thought that the program calculates them every single time.

 

I have no idea how Batari Basic does this, I code myself in assembler, writing my own routines.

You can count the numbers of WSYNC or use the TIMER.

Batari Basic works ok I guess (never tried it), I like to do it my own.

Sticking to the 4k originally assigned for games.

:-)

 

I wrote 2 VCS games myself the last 2 years.

Defend your castle / Give me my pancake!

Lots of fun and very challenging to write for the 2600.

Currently writing my 3rd game.

 

You can check scanlines/frames in stella, that is what I do.

Just hit the "`"-key to enter the debugger.

Click on Frame+1 and check the scanlines generated (previous frame) seen in the top-middle.

You can do simulated-IO on the IO-page (like pressing RESET or joystick-input) and look what it does to the scanlines.

Just be sure it generated 312 or 262 lines.

Stella has a powerful debugger.

 

Success,

Sijmen.

Link to comment
Share on other sites

Just got a chance to check this out. NTSC ROM is vertically scrolling on a real console, just as it is in Stella and Stellerator.

Since yesterday, I had to start it over maybe 5 times, because sometimes BB thought that it should recognize the Titlescreen part. So the first tactic was bad idea, to recreate every room and test it after it. Now I go from room to room and place every single object one by one and test it with the newest Stella, so I can see the picture vibrating. This will be a long job and I fear, some of my favorite rooms must be cut out.

Link to comment
Share on other sites

Maybe you can get some help with optimizing in the bB forum so you don't have to cut those rooms.

I'm at half way and has to make my favorite room with the mushroom today. Until now, I only had to cut out the mice, so the demon appears immidiately. And I made platforming easier and worked out a bug that caused the character invincible to enemies that damaged more than 1 by toucing.

 

It some rooms (like the demon I mentioned) the screen will "jump" a bit at enter because there are 264 cycles as it draws the playfield, but after that it will be the normal 262.

Edited by MemberAtarian
Link to comment
Share on other sites

It some rooms (like the demon I mentioned) the screen will "jump" a bit at enter because there are 264 cycles as it draws the playfield, but after that it will be the normal 262.

 

 

To fix that problem break up the new-screen logic to run over 2 or more frames. On the first frame update half the playfield, on the second frame update the other half. It'll occur so fast the user won't notice that it used an extra frame, but they will notice screen jitter caused by inconsistent scanline counts.

Link to comment
Share on other sites

 

 

To fix that problem break up the new-screen logic to run over 2 or more frames. On the first frame update half the playfield, on the second frame update the other half. It'll occur so fast the user won't notice that it used an extra frame, but they will notice screen jitter caused by inconsistent scanline counts.

I have two problems right now. One is, that I created a perfect collision with the stage, so you cannot fall between blocks of the pf and you can jump at the edge of the blocks without falling off, but it takes so many pfreads, even with using temp2 variable to save the !pfread(m,n) commands value if I have to use the same multiple times, that if a room has some action it goes again over 262 cycles.

 

The other problem is, that I'm out of variables. Most of them are neaded for moving and z for shooting and one for the health, y, o, u, s, r, w are used in every room differently, temp1, temp3 and b are useless, they mess with the code if I give them a value. I thought the same, that if b=0 then I calculate only one part of collisions and if b=1 then the other ones, and have every room draw the pf only at the beginning, but as I said, I have no more variables.

Link to comment
Share on other sites

When you break up init new-screen logic over multiple frames you don't process normal gameplay during those frames. No gameplay logic = no falling, so the first problem isn't really a problem.

 

Lack of RAM (variables) is almost always an issue with 2600 development, double so for bB due to how much RAM it needs for its own purposes. One way to solve that are to use bits within bytes, I talk about that in step 9 of Collect. In bB you'd do that using Bit Operations. Another is to reuse variables for different things depending upon what's occurring in the game - in Medieval Mayhem I reused the RAM that keeps track of the walls to draw the main menu.

Link to comment
Share on other sites

When you break up init new-screen logic over multiple frames you don't process normal gameplay during those frames. No gameplay logic = no falling, so the first problem isn't really a problem.

 

Lack of RAM (variables) is almost always an issue with 2600 development, double so for bB due to how much RAM it needs for its own purposes. One way to solve that are to use bits within bytes, I talk about that in step 9 of Collect. In bB you'd do that using Bit Operations. Another is to reuse variables for different things depending upon what's occurring in the game - in Medieval Mayhem I reused the RAM that keeps track of the walls to draw the main menu.

My luck in that you cannot go back to the prev room, so I made it that after leaving one, var0=1, and if var0=1, then it sets the playfield (after that, it sets var0 to 0), but there is no drawscreen during var0=1. So I had to make sure no playfield uses that variable and thats all. The only hard task right now is the mushroom trip, there the cycles always go over 262.

 

My next game will be a much simpler concept, with a Secret Quest-like layout, no jumps and complex playfields.

Link to comment
Share on other sites

You have to drawscreen periodically in bB to keep the screen stable, so to spread the init-new-level work over multiple frames you'd do something this (in psuedo code):

if var0 = 0 then
    normal gameplay logic
    drawscreen
else if var0 = 1 then
    set var0 = 2
    Update first half of playfield
    drawscreen
else if var0= 2 then
    set var0 = 0
    Update second half of playfield
    drawscreen
end if
Link to comment
Share on other sites

The only hard task right now is the mushroom trip, there the cycles always go over 262.

 

Break up the processing of the mushroom trip to spread it out over multiple frames. In Stay Frosty I do that for the moving platforms because the logic to shifting them takes a lot of overhead. Here's an example from level 32, if you can view each image in separate tabs of your browser you can switch between them to see the movement:

 

Starting position:

post-3056-0-40777100-1517682265.png

 

First frame the top 2 platforms move:

post-3056-0-14677500-1517682279.png

 

Next frame the bottom 2 platforms move:

post-3056-0-37644600-1517682285.png

 

After that no platforms move for 30 frames.

 

 

How that works is via the use of a Frame Counter, which increments by 1 every frame. Level 32's processing in psuedo-code:

if (frame & %11110) = 0 then
    if (frame & 1) = 0
      shift top two platforms
   else
      shift bottom two platforms
   end if
end if

 

If you're out of variables you can merge them with another - say your var0 from above which you use as 0 or 1 to denote leaving a room. If you use what I suggested with var0=0,1,2 then you could split var0 into 2 parts. There's 8 bits within a byte, often denoted by position as 76543210. Use bits 765432 for the frame counter and bits 10 for your leaving room logic.

 

Every frame do this to increase the frame counter bits:

var0 = var0 + 4

to break up your mushroom logic over 2 frames do this:

if var0 & 4 = 0 then
    mushroom logic even frames
else
    mushroom logic odd frames
endif

The prior logic I showed for multi-frame init-new-level would be this:

if var0 & 3 = 0 then
    normal gameplay logic - if room exited then var0 = var0 | 1
    drawscreen
else if var0 & 3 = 1 then
    set var0 = var0 + 1
    Update first half of playfield
    drawscreen
else if var0 & 3 = 2 then
    var0 = var0 & %11111100
    Update second half of playfield
    drawscreen
end if
  • Like 1
Link to comment
Share on other sites

It's been years since I've used bB, but I imagine this is still the case - no matter where you put your graphic data in the program, it gets relocated to whatever the last bank is (in this case bank8) at compile time. Try commenting out a sprite and see if the size of bank 8 changes when you compile it..

Edited by s0c7
Link to comment
Share on other sites

It's been years since I've used bB, but I imagine this is still the case - no matter where you put your graphic data in the program, it gets relocated to whatever the last bank is (in this case bank8) at compile time. Try commenting out a sprite and see if the size of bank 8 changes when you compile it..

Great, I will try to do something. If it won't work, I remove the boss and make the other parts harder, because the last boss was really fustrating, because you have to shoot the first time and the continues and the bullets both use the collected herbs, so you could drain yourself to game over in a minute. :D

Link to comment
Share on other sites

After so many hours of suffer and guilty, I polished a nearly finished version of Plague. I removed one room and the final boss to make it fit into the strange logic of the compiler. I won't spoil the ending, it's different from the one I made last time. :D

 

It's only NTSC for now, in the next days I gonna create the PAL50 and PAL60 versions and test in on the real hardware. In Stella, in 99% of the cases there was 262 cycles before the drawscreen, so I hope now it works and there won't be any scrolling.

 

I changed some parts of the game, jumping must be easier, but herbs gives you lesser continues and the inverted cross boss is much harder from now.

 

EDIT:
If the left switch is in hard mode, the herb only gives you 1 points, in easy, you gain three of them!

Plague NTSC 1.32.bas.bin

Edited by MemberAtarian
  • Like 3
Link to comment
Share on other sites

I played it a few times. There wasn't any scrolling issues, but it was very difficult to make jumps. I would intend to jump once, but end up jumping twice, which would usually cause me to fall in a pit and die. I noticed a bug in the areas where the paths fall away as you run across them. on the high path, I went to the end and got the herb, but I got stuck in the wall and had to reset. Then a couple of games later, on the lower path, it fell away and dropped me on the bottom to the left of the herb, so I tried to jump over the the herb and hit the edge where the path fell away and got stuck in the wall there too. I also never got the fire button to work, I thought maybe I was missing something, but if not, that would be a bug too. Overall though, I'm liking the game. It looks great and I can't wait to play the finished version.

Link to comment
Share on other sites

I played it a few times. There wasn't any scrolling issues, but it was very difficult to make jumps. I would intend to jump once, but end up jumping twice, which would usually cause me to fall in a pit and die. I noticed a bug in the areas where the paths fall away as you run across them. on the high path, I went to the end and got the herb, but I got stuck in the wall and had to reset. Then a couple of games later, on the lower path, it fell away and dropped me on the bottom to the left of the herb, so I tried to jump over the the herb and hit the edge where the path fell away and got stuck in the wall there too. I also never got the fire button to work, I thought maybe I was missing something, but if not, that would be a bug too. Overall though, I'm liking the game. It looks great and I can't wait to play the finished version.

These are the things I want to work out somehow. Really hard to make a proper platformer with just 262 cycles, I only have enough cycles to call pfread for a few times. :/

Link to comment
Share on other sites

Yeah, I'm getting stuck in the play field a lot. Unless I'm very careful, I am always stuck in the wall after the collapsing bridge. Also, while I love the B&W theming, it makes it very hard to know what is a pit and what is solid ground. Can the pits just be left empty? By the time I got to the dark screens, I was pretty much done. It is far too easy to double jump and I'm not sure what the fire button is supposed to do, but it's not doing much right now.

 

All of that said, I still think this is a fascinating concept with some very promising ideas driving it! Can't wait to see it develop further!

Link to comment
Share on other sites

Yeah, I'm getting stuck in the play field a lot. Unless I'm very careful, I am always stuck in the wall after the collapsing bridge. Also, while I love the B&W theming, it makes it very hard to know what is a pit and what is solid ground. Can the pits just be left empty? By the time I got to the dark screens, I was pretty much done. It is far too easy to double jump and I'm not sure what the fire button is supposed to do, but it's not doing much right now.

 

All of that said, I still think this is a fascinating concept with some very promising ideas driving it! Can't wait to see it develop further!

 

Today I'm still working on my current yt video, but after midnight I finally get again to do a little bit debugging.

 

You are right with thouse bugs. There is a way to make the score field black without turning the last block of background black as well, so I will try. The pf blocks are a different story, if the VCS would have more scanlines for calculations, I could easily detect collision if there would be more pf reads, but it's one of the most costful commands (so costful you cannot use two of them in the same if then), I have two for checking things under you, on to check things over you and two for both sides.

 

The fire button is only used after you fought the cross (yeah, you have to beat the boss without a weapon!) and you only use it to cure (or kill, if the elixir is wrong) the people. If splitting the rooms wouldn't eat more space, the last boss would be beatable with the elixir, but unfortunately I had to remove that part.

Link to comment
Share on other sites

...There wasn't any scrolling issues, but it was very difficult to make jumps. I would intend to jump once, but end up jumping twice, which would usually cause me to fall in a pit and die.

...It is far too easy to double jump and I'm not sure what the fire button is supposed to do, but it's not doing much right now...

...The fire button is only used after you fought the cross (yeah, you have to beat the boss without a weapon!) and you only use it to cure (or kill, if the elixir is wrong) the people...

 

I played it for a while yesterday on my Flashback HD (it works great, except for the title screen of course), but I ended up being too frustrated by the jumping control. Since jumping is the biggest part of the game and requires more precision, I think it should be controlled with the button. This would also help keep us from accidentally jumping multiple times. For the control of using an herb, which is used less often and does not require such precision, I think pressing up would be more fitting.

 

Using the button, resulting in less accidental jumps, would probably also result in less getting stuck in the playfield. Besides that, the game looks great and I'm looking forward to seeing it completed. Awesome work so far!

Link to comment
Share on other sites

 

I played it for a while yesterday on my Flashback HD (it works great, except for the title screen of course), but I ended up being too frustrated by the jumping control. Since jumping is the biggest part of the game and requires more precision, I think it should be controlled with the button. This would also help keep us from accidentally jumping multiple times. For the control of using an herb, which is used less often and does not require such precision, I think pressing up would be more fitting.

 

Using the button, resulting in less accidental jumps, would probably also result in less getting stuck in the playfield. Besides that, the game looks great and I'm looking forward to seeing it completed. Awesome work so far!

Maybe you are right, the button should be the button and using the medicine should be up in the last scene?

Link to comment
Share on other sites

I think these may be the final versions.

 

PAL:

 

PAL60:

(flicker and interference is because my recorder can really not handle 60Hz)

 

I did not record the NTSC because I don't have an NTSC console, Z26 emulator does not emulate the timing errors and somehow even the older and the current Stella both does not want to let Fraps record my gameplay, only the sound.

 

There were things those I could work and and some that I couldn't. Mostly because of the 262 cycles.

.Now, as asked, the fire button makes you jump, so on the last part as you are shooting sick people you have to use UP for shooting. It's a really easy part, so it won't disturb you hopely.

-I tried to go under 262 cycles as possible, that was the most disturbing thing, creating a lot of jumps if something is not needed. You can see that there are some levels where you can jump on platforms under them, it's because I had to turn off pfreads for those parts, that is the command that eats most of the cycles. Sometimes it will happen in the NTSC and PAL60 versions, with PAL you have more cycles, so it works perfectly, but it's slower because of the 50Hz.

-There will be some glitches, it's because I would need TWICE of the pfreads to make sure if there is an object in front of you, over you or under you. The hardest part was jumping, so I had to make strange decisions in coding that I am not proud of.

-Unfortunately, I had to cut the last boss because of the strange sprite placement of BB, it puts them into the last bank no matter what and of I don't want to put them all there, creating a long cycle that causes overload again and sometimes, I could cry instead of shouting and hitting the desk or the keyboard. :D

-I tried another way to make the score background black, but make the last row of background gray, so you could recognize holes easier, I could insert this little code

 

asm
minikernel
sta WSYNC
lda $00
sta COLUBK
rts
end

 

into vblank, but it left out a lof and there was a lot if gray under the last row of blocks (BB leaves the 12th row empty for vertical scrolling), and to be honest, it looked uggly.

 

-You can press Select, it does the same thing on the titlescreen as reset, I used it for testing and jumping to the desired room, now it goes to room0. I wanted to remove it, but if I do it, the game won't load the main cycle with the gameplay. Why won't it? Don't know, BB has some really strange and unfair things, sometimes it "creates errors" while compiling that makes no sense.

 

I think other errors were corrected that I found while testing, if you find more, please, tell me!

I attached the code of someone is curious about it.

https://www.4shared.com/archive/q19JSx1jca/titlescreen.html<< The title screen for assembling.

PlagueFinalPAL60 1.01.bas.bin

PlagueFinalPAL50 1.01.bas.bin

PlagueFinalNTSC 1.01.bas.bin

PlagueFinalNTSC 1.01.bas

Edited by MemberAtarian
  • Like 6
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...