LoginLogin
Might make SBS readonly: thread

Digital Derby DS

Root / Submissions / [.]

ArchiveCreated:
Download:SDEXE8HE
Version:0.0.1Size:12.68 KB
Weave through traffic in this simple but addicting Text Mode road racer. Inspired by the analog handheld from 1978.

Instructions:

D-Pad=Left/Right; A=Faster; B=Slower; Score increases when cars are passed and decreases when something is hit. Race time is two minutes.

Notes:

Quit with R+X to see runtime stats...

Cool! How do you detect system?

Replying to:joelable
Cool! How do you detect system?
Not author, but The HARDWARE system variable. It's 0 if you are using the normal 3ds, but 1 if you are using the new 3ds.

Replying to:joelable
Cool! How do you detect system?
Nice. Thanks.

if you use VSYNC (rather than WAIT), then there should be no difference between the two consoles. VSYNC counts time from the last time you used VSYNC, so either way you'll get the same framerate (unless it took too long to run the game loop, in which case VSYNC doesn't wait at all) Consider the following code:
@LOOP
' code here that takes anywhere between 3 and 7 frames to run
VSYNC 10
This loop will be repeated exactly 6 times per second. TL;DR no calibration needed, use the same VSYNC value anyway.

Replying to:NeatNit
if you use VSYNC (rather than WAIT), then there should be no difference between the two consoles. VSYNC counts time from the last time you used VSYNC, so either way you'll get the same framerate (unless it took too long to run the game loop, in which case VSYNC doesn't wait at all) Consider the following code:
@LOOP
' code here that takes anywhere between 3 and 7 frames to run
VSYNC 10
This loop will be repeated exactly 6 times per second. TL;DR no calibration needed, use the same VSYNC value anyway.
Yeah, your @CHECK_SPD routine can just be replaced with VSYNC. Both systems will run at the same speed.

Good game but the cars are too predictable. You should add random speed at the car creation and put a random cooldown from each spawn(At the moment, I notice that the car spawn as soon as they get to the bottom of the screen). Also, A and B make the time go faster or slower. Instead, you should have a global variable to store the "base velocity" of the other cars and increase or decrease it when the player press A or B. PS: I have a normal 3ds and it goes at the right velocity when I don't press A or B.

Replying to:NeatNit
if you use VSYNC (rather than WAIT), then there should be no difference between the two consoles. VSYNC counts time from the last time you used VSYNC, so either way you'll get the same framerate (unless it took too long to run the game loop, in which case VSYNC doesn't wait at all) Consider the following code:
@LOOP
' code here that takes anywhere between 3 and 7 frames to run
VSYNC 10
This loop will be repeated exactly 6 times per second. TL;DR no calibration needed, use the same VSYNC value anyway.
Great! Just the info I was looking for, Thanks a ton, guys!!! I have a question though, why do some of the early games released in Japan (before NA's release, and written on org. 3DS's) run at a blurring speed. I'm sure it's not as the author's intended. Not challenging, just unplayable. I saw a youtube video where the game (can't remember which) was running at the normal speed on a reg 3DS but ran at breakneck speed on my N3DS. Another, not as extreme, example of this is the included Example program EX7Alien. It seems just a notch to fast on a N3DS, you can't even really see the missile graphic. Drop it down a notch and the game seems more like it was intended. Also, what about those tests that show how much faster the N3DS runs loops and such? Seems like you might need to adjust speed to account for that...really glad if that's not the case. Much easier, haha!

Replying to:raimondz
Good game but the cars are too predictable. You should add random speed at the car creation and put a random cooldown from each spawn(At the moment, I notice that the car spawn as soon as they get to the bottom of the screen). Also, A and B make the time go faster or slower. Instead, you should have a global variable to store the "base velocity" of the other cars and increase or decrease it when the player press A or B. PS: I have a normal 3ds and it goes at the right velocity when I don't press A or B.
Some really good advice here, thank you! I played around a bit with randomizing the cars (left some of the code in there) but it required to many case checks to make sure the player always a free route to travel. Without the checks, it was too frustrating, and felt unfair to the player, so I ditched the idea. These smaller games are really just exercise's to help me improve so I really appreciate the input, from you all!

Replying to:NeatNit
if you use VSYNC (rather than WAIT), then there should be no difference between the two consoles. VSYNC counts time from the last time you used VSYNC, so either way you'll get the same framerate (unless it took too long to run the game loop, in which case VSYNC doesn't wait at all) Consider the following code:
@LOOP
' code here that takes anywhere between 3 and 7 frames to run
VSYNC 10
This loop will be repeated exactly 6 times per second. TL;DR no calibration needed, use the same VSYNC value anyway.
Same reason really old computer games (from the 8-bit era) run too fast on later machines. The code was written without any time syncing, it was ONLY based on how fast the CPU could run. So a lousy programmer on an O3DS would write his game without any VSYNC or WAIT at all, and it would run fine on his own machine because it's exactly the right speed and he calibrates based on that.. but on a N3DS it's a lot faster. Code that uses VSYNC will never have this problem, UNLESS the O3DS is not fast enough to keep up with the target framerate.

Replying to:NeatNit
if you use VSYNC (rather than WAIT), then there should be no difference between the two consoles. VSYNC counts time from the last time you used VSYNC, so either way you'll get the same framerate (unless it took too long to run the game loop, in which case VSYNC doesn't wait at all) Consider the following code:
@LOOP
' code here that takes anywhere between 3 and 7 frames to run
VSYNC 10
This loop will be repeated exactly 6 times per second. TL;DR no calibration needed, use the same VSYNC value anyway.
Yeah, if you just use regular VSYNC the worst thing that could happen is that the O3DS runs slower than the N3DS. In your case, my assumption is that the code is fast enough to be locked at 60FPS.

Replying to:NeatNit
if you use VSYNC (rather than WAIT), then there should be no difference between the two consoles. VSYNC counts time from the last time you used VSYNC, so either way you'll get the same framerate (unless it took too long to run the game loop, in which case VSYNC doesn't wait at all) Consider the following code:
@LOOP
' code here that takes anywhere between 3 and 7 frames to run
VSYNC 10
This loop will be repeated exactly 6 times per second. TL;DR no calibration needed, use the same VSYNC value anyway.
Ok cool. I'm trying to wrap my head around all this and you guys are helping a bunch. Seriously, thank you! I understand the difference between WAIT and VSYNC much better now. This tiny game gave me a lot of trouble with flashing/stuttering until I weaned out the WAITS and placed the VSYNC with care. Oddly enough using BGMPLAY (custom mml on track 0) also caused slowdown so I went with BEEPS instead. I'm so relieved that I don't have to worry about timing differences for the simple programs I write, as long as I use VSYNC wisely.

not my type of game, but good job!