My 2k Game Experiment - Gate Racer

[+Atarius Maximus]

Since you only have one gate on the screen at the time, "pfclear" is overkill. If you replace pfclear with "var44=0:var45=0:var46=0:var47=0" in your test program it will run at 262 consistently. Hopefully it will do the same for the real game.

 

Also, nice little game!

Thanks for the suggestion, RevEng. I think someone else mentioned using the var44-47 varibles earlier in this thread but I scratched it because it used more ROM space. I didn't realize it was much more efficient than using pfclear. If it solves the scanline problem, it's absolutely worth sacrificing something else to fit it in. I'll give it a shot tomorrow, out of time today for atari related stuff.

[+Atarius Maximus]

Thanks for the suggestion, RevEng. I think someone else mentioned using the var44-47 varibles earlier in this thread but I scratched it because it used more ROM space. I didn't realize it was much more efficient than using pfclear. If it solves the scanline problem, it's absolutely worth sacrificing something else to fit it in. I'll give it a shot tomorrow, out of time today for atari related stuff.

 

I spent a great deal of time looking at the CPU time for every single command in this code that I used, it took a long time to figure out what was causing the scanline count to jump over 262. I commented out every extra feature individually and re-tested to try and find the cause of the problem. It looks like changing pflcear to "var44=0:var45=0:var46=0:var47=0" in the subroutine that changes the gate barrier did make a difference (although I still need to use a pfclear when you crash to reset everything). The biggest culprit was "pfvline 0 0 11 on" and "pfvline 31 0 11 on". I actually couldn't even figure out a way to use any pfpixel command in the main loop without seeing a jump over 262. It looks like the only way to make this game hardware compatible is to only use the PF0 command for the sides of the road, any commands that draw pixels on the screen cause more than 262 scanlines when you scroll them. I'm stil working on some additonal (minor) tweaks to the game, but leaving out any pf commands seems to be the compromise I need to make to make this game hardware compatible. I liked the individual pixels on the sides of the road to give a better sense of road movement (since the lines in between the pixels show the scrolling better), but they're going to have to be left out of the final version. I'll post the updated final version later tonight or tomorrow. None of my minor changes are going to change the gameplay, all the current high scores will still be valid. I'm still thinking it may be a bit too easy as I can routinely get over 4 minutes on a game, though.

[Cybearg]

How much space do you get freed by cutting out those pfvline routines? Because if you had enough room, you could draw the line by writing full %11111111 to all the variables necessary to make it, then randomly choose a bit to start at and flip a number of bits determined by another random number.

[+Atarius Maximus]

How much space do you get freed by cutting out those pfvline routines? Because if you had enough room, you could draw the line by writing full %11111111 to all the variables necessary to make it, then randomly choose a bit to start at and flip a number of bits determined by another random number.

I don't recall exactly how many bytes were freed up by removing those commands because I was making so many changes at once. I would guess each pfvline command uses 10-12 bytes each at the most. Every time I make a change and free up space I keep making changes to the title screen. I know it's not important, but I do like a nice titlescreen. I'm not sure which variables I would use to to replace the pfvline commands, do you know? The comments made earlier in this thread about the var44-47 commands were new to me, I didn't know about that either.

[Cybearg]

Sorry, I've never tried it myself, I just know it's a thing. Hopefully someone with more knowledge can offer suggestions.

[+Atarius Maximus]

I had a really fun evening tonight with my youngest son, age 10. He was interested in what I was doing with the Atari since I rarely have it upstairs, and I talked to him about the newest game I was working on. He was eager to try it and I told him about my best score and Horeus' best score after he'd played a few rounds. He was incredibly determined to beat the best time and played the game for almost an hour. Incredibly, his best score was an 8:33.0 after playing for less than one hour. Maybe my 40+ year old reflexes aren't what they used to be, or maybe this game really is too easy! I'm now seriously considering at least making a harder difficulty level for all the 10 year olds out there that might play my game! I can let the cool titlescreen go, you only see that once anyway. I attached a pic of my son's high score and his proud smiling face next to the old 1702 monitor. I also attached the latest WIP build that works on real hardware. It's not going to be the final version, but I needed to post it in case anyone wants to challenge my son.

gr2.txt.bin

[Cybearg]

Instead of having to change anything, could you just adjust the numbers so that there are 2 minute numbers and 2 second numbers? Yeah, it's a little odd for a racing game to not have milliseconds but it'd pretty much guarantee no one would go beyond the highest possible score without any actual code being added.

[+Atarius Maximus]

Instead of having to change anything, could you just adjust the numbers so that there are 2 minute numbers and 2 second numbers? Yeah, it's a little odd for a racing game to not have milliseconds but it'd pretty much guarantee no one would go beyond the highest possible score without any actual code being added.

Very true Cybearg, very unlikey anyone would want to play this game long enough to get past 99 minutes. I have no idea how difficult that would be as I didn't write the timer code, it was a minikernel that Michael Rideout (SeaGtGruff) wrote a long time ago, not sure if I could modify it or not as I'd have to take a closer look. I could send him a PM about it, or if he's reading this thread maybe he could comment...

[RevEng]

The cheapest way to get your side-blocks back in (12 bytes) would be to add the following right before your "pfscroll down"...

 

var44=var44|%10000000

var47=var47|%10000000

 

The screen will start blockless after each pfclear and blocks will scroll down. I don't think it's an objectionable approach.

 

You probably already did so, but don't forget to whack the pfvline assembly from your custom pf_drawing.asm.

[Horeus]

One word for your son :

Do it better will be difficult

Congrats Josh

Edited February 26, 2013 by Horeus

[+Atarius Maximus]

The cheapest way to get your side-blocks back in (12 bytes) would be to add the following right before your "pfscroll down"...

 

var44=var44|%10000000

var47=var47|%10000000

 

The screen will start blockless after each pfclear and blocks will scroll down. I don't think it's an objectionable approach.

 

You probably already did so, but don't forget to whack the pfvline assembly from your custom pf_drawing.asm.

That worked as far as staying at 262 scanlines, but I'm not sure I like the effect. Until the blocks scroll all the way down there is one block at the bottom (on each side) that flickers and bounces. It's kind of distracting and not very visually appealing. Maybe there's a way around that.

 

EDIT: RevEng - I did see your comment about putting it right before "pfscroll down". It's not at that location in the attachment because I was moving it around to see if it made any difference. I did remove the pfvline from pf_drawing.asm, just attached that as well.

gr2test.bin

gr2test.txt

pf_drawing.asm

[RevEng]

I see what you mean. It's caused by the last row being exposed by scrolling. Try using this instead...

 

var0=var0|%10000000

var3=var3|%10000000

 

...and for your pfclear replacement line use this instead...

 

var44=%10000000:var47=%10000000:var45=0:var46=0

 

...That should give a smooth effect. I'd test myself, but I don't have your other modified bB asm files.

[+Atarius Maximus]

I see what you mean. It's caused by the last row being exposed by scrolling. Try using this instead...

 

var0=var0|%10000000

var3=var3|%10000000

 

...and for your pfclear replacement line use this instead...

 

var44=%10000000:var47=%10000000:var45=0:var46=0

 

...That should give a smooth effect. I'd test myself, but I don't have your other modified bB asm files.

That worked perfectly. Thanks for your help.

gr2test.bin

[iesposta]

That worked perfectly. Thanks for your help.

Original vision fulfilled! My best time: 1:04.3

[Brian O]

Has anyone come up with a nice retro label yet?

 

I didn't come up with a retro label, but I had an old design I created for a game concept called "RAILZ" a while back, which was in the same vein as this game. I just updated the game's name to "Gate Racer." It's yours if you want it, AM.

 

 

 

 

-B

[+Atarius Maximus]

I didn't come up with a retro label, but I had an old design I created for a game concept called "RAILZ" a while back, which was in the same vein as this game. I just updated the game's name to "Gate Racer." It's yours if you want it, AM.

 

 

 

 

-B

Not sure why, but they show up as red X's for me. Maybe you could add them in a zip file and reattach? Thanks.

[Brian O]

Not sure why, but they show up as red X's for me. Maybe you could add them in a zip file and reattach? Thanks.

 

That's weird. I've attached them instead of just pulling from Imgur.

 

Let me know if you still get red Xs.

 

Thanks,

B

[+Atarius Maximus]

Looking at the forum on my iPhone I can see the pics fine. Maybe imgur is blocked at work. I love the label, looks very professional. I'd like to use it for a personal copy of the game. I'll send you a PM later, I'd like a hi-res copy for printing if possible.

[Brian O]

Looking at the forum on my iPhone I can see the pics fine. Maybe imgur is blocked at work. I love the label, looks very professional. I'd like to use it for a personal copy of the game. I'll send you a PM later, I'd like a hi-res copy for printing if possible.

 

I have the high-res front and end labels ready whenever you want them. Let me know.

 

-B

[+Atarius Maximus]

I think there may be some duplication in having both a title screen sprite and an in-game sprite. Couldn't you just have the title screen sprite then adjust the player0pointerhi and player0pointerlo for in-game (cutting out the "GR" part)? Or, maybe separate out the "GR" part as player1 and re-use the in-game player0 sprite?

 

The slide is bearable now. Thank you

 

I'm still interested in seeing if "player0pointerhi = rand" is a good way to make a crash sprite for free. My only concern is does the trick work on real hardware?

Using "player0pointerhi=rand" works perfectly on real hardware. I kind of like that as a crash sprite, I'll throw it in to the next version.

[+Atarius Maximus]

Here's the latest version. I'm really close to calling this done, I've got everything I wanted in the game and I'm down to about 6 bytes free. I freed up some more space from the last revision by removing some unneeded code from the source and making a few more changes to the standard include files. I was able to create a proper titlescreen like I wanted, make the oil slick back into a sprite, and add the random bit pattern crash on the sprite. The oil slick is bigger now, which is what I'd originally wanted. There were some other tweaks here and there to polish it up... like the titlescreen graphics and car don't flash different colors and appear in the middle of the screen when you restart after crashing. I added some pics that show the new titlescreen and oil slick. I'll update the first post within the next day with all the new include files and source code.

 

EDIT: Forgot to mention one other thing. This version is 100% hardware compatible.

GateRacer_RC1.bin

[Cybearg]

Did you find any explanation as to why the side walls have lines in them sometimes? At first, when you immediately start, the walls are smooth, but then they move in a bit and get those segmented lines partway through. Any idea why there is that inconsistency?

 

It all seems very solid to me. Great timer graphics and I like the title screen. All very well done within the limitations.

 

I noticed just one thing off--when the car crashes and the crash noise goes to silence, it isn't fully silent. There is a bit of electronic buzz, like it's not fully muted or something.

[+Gemintronic]

Did you find any explanation as to why the side walls have lines in them sometimes?

 

He's not using the no_blank_lines option. Those gaps are natural - kinda like waking up after new years in the tub with a frying pan.

[Cybearg]

He's not using the no_blank_lines option. Those gaps are natural - kinda like waking up after new years in the tub with a frying pan.

That's what I would have thought, but then why aren't there any lines there when the game first starts?

[+Atarius Maximus]

That's what I would have thought, but then why aren't there any lines there when the game first starts?

It was a compromise. Using phvline uses too many CPU cycles, and using the playfield command uses too much ROM space. RevEng helped me with a method to keep the blocks on the screen at the expense of having them scroll down from the top when the game first starts (see post #87). I like how the game looks with the blocks, it gives more of a sense of road movement. It's a compromise I'm happy with. The sides of the road that show up before the blocks start scrolling is created with the PF0=200 line.

 

As far as the audio having a slight buzz, I noticed that too. Not sure what's causing it. I'll take a closer look.