Tron Light Cycles for Colecovision - Work in progress

[+Tarzilla]

By now you probably found this link, but I'll put it here for reference

 

http://www.msxblue.com/manual/debugger_c.htm

 

You should be able to play until just before the black screen, then switch to debugger mode and step thru the code. Does the compiler generate any listing or debug files besides the rom? You may have to investigate the command line of the compiler.

[parkfun101]

Thanks Tarzilla, I did already find the link, but I think you'd have to know Assembly language really well to understand how to read it. Also, trying to predict when the black screen comes up seems to be more and more difficult to predict. I don't think the compiler generates any debug files for the rom. I also don't think this compiler even has a command line interface.

[Pixelboy]

Thanks Tarzilla, I did already find the link, but I think you'd have to know Assembly language really well to understand how to read it. Also, trying to predict when the black screen comes up seems to be more and more difficult to predict. I don't think the compiler generates any debug files for the rom. I also don't think this compiler even has a command line interface.

Doesn't it offer breakpoints, at least?

[+Tarzilla]

http://atariage.com/forums/topic/187160-cci3-alpha-version/

 

Based on this thread, my guess is that you are actually using a wrapper tool created by Daniel B that uses a windows interface to shield you from the actual Sdcc command line compiler, which itself has all kinds of options.

[parkfun101]

int SCORE[2], SCORE_P1[4], HISCORE[4];

Ok, As a test, I commented out all the SCORE variables. SCORE is for the actual score of P1 and P2, HISCORE is the hiscore for each of the modes and there is another variable that I use for passing this on to the title screen.

 

I did a Fast Test using the cheats and there were NO problems. I got all the way to 201 levels without any glitches at all. I'll do a few more Fast Tests to make certain I can consistently get to level 201 to confirm it is the actual problem. I'll do a slow play test in about an hour or so and see if I can get to perhaps level 100 without it breaking. Usually, when I get past around level 87, the game would flicker and then display the screen, but this time there were no glitches what so ever. I need to test this several times to make certain if this part of the problem. It is not necessarily the score variables, it could be something I'm doing with the score at some point during the game. This is promising.

[+Tarzilla]

I'm not near a desktop so I can't be more helpful with actual examples but if you've narrowed it down to the score variables, you should be able to put something in the score functions like

 

debugtxt='step1'

 

that shows up in the various debugger screens of BlueMSX, combined with the debugger tools for checking memory

[parkfun101]

I've just done 3 FAST tests in a row and each time I could get to level 201 without ANY issues! Later on tonight is the real test, the actual slow Play testing. If all goes well, I'll later work on re-adding the scores back in a little at a time. First the SCORE and then test ....test....test and then the HISCORE and then test....test....test. I honestly don't know why I have a HISCORE variable and then another variable for displaying it on the Title screen. I could just use the HISCORE variable to display there. I probably threw that together and went on to something else, but if I'll look into it.

I'm not sure if I'm going to use the Debugger tools for BlueMSX yet since they seem very foreign to me. I don't exactly know what I'm looking at in BlueMSX. I may not even need it anyhow if the score is the cause of this problem. I want to do at least 2 more FAST tests and then about 2 or 3 slow Play tests to see if I can get to level 101 or further...hopefully 150 or so without fail. If I can, it is safe to say I will have isolated the problem area. The scores, earlier on in development, had caused some weird screen problems before after playing for about 10-15 mins or so, so it wouldn't surprise me if this is the problem again.

After the slow Play Tests (with no score variables), I'll post the results. Hopefully they will be good. After that, I'll work on a fix for the problem. Thank you Tarzilla, Pixelboy, and Kiwi for your ideas for trying to resolve these issues. I really want this to be a great game and hopefully a fun and memorable one as well. This issue is just a wrench being thrown into my plans, but hopefully, I just found the wrench. Crossing my fingers.

[Kiwi]

I'm thinking that int would take more cycles as the score grows bigger due to it multiplying 2 value to get 16-bit number. The maximum would be 65535, that it would have to multiple 256, 256 times. If the score being calculated and drawn every frame, it may be running out of cycles.

You can see the cycles being use in a frame doing this trick I learned from nanochess. Add paper(2); before your delay(1)[ the one acting as a vsync] and paper(14) after delay(1). It gives the vdp command to change border, and it'll draw the border. Then when all the processing is done, then paper(2) is what left over and forcing the CPU to wait for display to finish drawing.

paper(2);
delay(1);
paper(14);

It would look like this.



It is processing the gravity, and the print_at(0,0,str(debug)); routine. The gray is cpu waiting for the vsync to occur.

So I'm thinking int is what might be the problem since it is multiplying value doing recursive adding. As the number get bigger, then more calculation is requires.

Just wanted to give you my theory what may be causing the crash.

[parkfun101]

That makes sense and with all the other things going on besides just the score like wall and line detection, other counters adding up, etc, etc, the score perhaps pushes the envelope a bit too much later on in the levels. When I'm ready to try to add the score back in, I could maybe put some code in that once the score is over a certain amount, it could insert a delay(1) or so to see if that gives more time when it does any score calculations.

[parkfun101]

Ok, I did a normal Play Test (not a FAST test) with no SCORE values that took well over an hour. For testing, my game has been set to have no Win or Loss sounds which reduces the time it takes to test. I had to continue a bunch of times and I got up to Level 179 before the game blacked out. This is a HUGE improvement from the game blacking out during my Play Tests when it normally would Black Out anywhere from Level 35 to 55 or so. This makes more sense that the game may be having to do a lot of calculations and I may just need to give it a bit more time to figure things out. I'm so used to newer coding languages that I'm a bit spoiled....I've got to pretend it's 1982!

 

I'll have to look and see where I can put some delays in to give the game more time to calculate complex parts or change how and when the score calculates. I suppose for bike crashes, I could put in a small delay so the score could add up each time. I wonder if that is why in Pac-Man games, the game pauses when a ghost is eaten....so they give time to calculate maybe??? I think in most games, this Score issue wouldn't be much of a problem, but when you have 4 bikes moving around, speed timers, flicker testing, modulus tests so the bikes know when they are allowed to turn, etc., etc., the computer just works too hard and eventually can't take it anymore, I guess.

Kiwi, do you think that providing delays may be all that is needed or do you also think that I need to eliminate the int values for score all together and perhaps do what Tarzilla said about using a combination of bytes to create a score display?

[parkfun101]

I think I know one reason I may be having some issues besides the score, the modulus. The game basically gets each bikes' X value and Y value and divides by 8 and returns the remainder for each bike on the screen all the time. Instead I could use a switch statement like:

 

Instead of:

XVal = X[PlNum] % 8; //Modulus - Keeps player in a grid like pattern of 8 x 8

 

 

I could do:

switch ( X[PlNum] ) { //Keeps player in a grid like pattern of 8 x 8
case 0: case 8: case 16: case 32: case....
XVal = 0; //Bike's X value is allowed to turn on the grid
break;

}

 

This would require NO division which should help the computer out a bunch, I would think.

[parkfun101]

I think the modulus and some other code I had was one of the main problems. I've now added a very small delay(not noticeable) when a bike crashes to help let the score add up. I just Play tested and with the SCORE in place, I could get all the way up to level 184. Normally, this would have taken someone over 3 hours to get that far, but I had some pauses removed to help test quickly.

 

So, what I've learned from this issue is that when you are coding for Colecovision, it is a good idea to make it so the game doesn't have to be so calculation heavy. Too many calculations at once may cause Black outs in the game.

 

So instead of this:

plus = (PlNum-1) << 3; //<< is the same as * 8

 

Do something like this instead:
switch(PlNum){
case 1: plus = 0; break;
case 2: plus = 8; break;
case 3: plus = 16; break;
case 4: plus = 24; break;
case 5: plus = 32; break;
}

 

The 2nd example has NO calculations.

 

After testing this, it makes me wonder how many Colecovision games could get to level 184 or more without breaking? Even Pac-Man in the Arcade glitches eventually. What was kind of cool, when I got to level 184, there were no walls, but I could still play.

[parkfun101]

Finally, I can work on the game besides that major bug fix . Last night, I updated the title screen from Light Cycle Racing to Light Grid Racing. Here is a screenshot. This may not be the final version, but I think it will look pretty close to this.

Light Grid Racing - Title Screen - Looks better when you view it from full size.

Also, for myself and anyone who wants a faster game to try to get the hiscore, I'm planning on leaving the "0" button in as an alternative to start the game. This button skips the "...10000 BONUS..." screen and the Tron Controller and instructions. It also doesn't have a delay when you Win or Lose a match. This was very helpful for me trying to debug the Black Out issue. Not the coolest Easter egg, but it's there now.

 

[+Tarzilla]

Looks great! Glad you can move on from that bug.

[Kiwi]

Kiwi, do you think that providing delays may be all that is needed or do you also think that I need to eliminate the int values for score all together and perhaps do what Tarzilla said about using a combination of bytes to create a score display?

I'm really sorry I missed this until now. The z80 processor do 8-bit math in register AF, which holds the accumlator and the processor flag. If you're calculating 16-bit numbers it would have to do more work. Putting delay would help, it'll give the processor fresh new cycles. I was wondering what the score was at when it blank out. I think multiplication being done to display the score is what killing the cycles. The higher the score, the more multiplication is done to that value.

 

I would recommend doing array of bytes. You can have multiple of digits score. Can directly increase one digit such as if I want to add 1000 points, then score[3]++; would do the trick. Then have a subroutine to check if the digit is higher than 10.

 

For my projects, the scores are in 3 to 5 bytes, which holds the digit value. I have it that if that digit is more than 10, then the next digit increase, and the current digit is subtracted by 10. It looks kinda like this from my Adventure of a Witch project.

 

void AddScore(void){
if (digits[0] >= 10){digits[1]++;digits[0]-=10;}
if (digits[1] >= 10){digits[2]++;digits[1]-=10;}
if (digits[2] >= 10){digits[3]++;digits[2]-=10;}
if (digits[3] >= 10){digits[4]++;digits[3]-=10;}
if (digits[4] >= 10){digits[5]++;digits[4]-=10;}
if (digits[5] >= 10){digits[5]=9;digits[5]-=10;}
}

void DrawScore(void){
put_char(30,1,digits[0]+48);
put_char(29,1,digits[1]+48);
put_char(28,1,digits[2]+48);
put_char(27,1,digits[3]+48);
put_char(26,1,digits[4]+48);
put_char(25,1,digits[5]+48);
}

Currently I can have value 0-99 holding in one variable. I can display them by doing division by 10 and mod by 10, then using put_char command to display the value.

a=Atk/10;
b=Atk%10;
put_char(0,10,'A');
put_char(2,10,a+48);
put_char(3,10,b+48);

The downside, the high score comparison is a bit trickier to do.

[parkfun101]

Thanks Kiwi for that code example. I'll have to try that out. After play testing, I think the main problem was a combination of too many calculations at one time using the modulus to figure out when bikes were "allowed" to turn depending on what X and Y pixel they were on. The checking for this was happening all the time for every bike on the screen and I could only get to about level 87 during a Fast game test. After I replaced those calculations with a hefty switch statement that stores the exact pixel numbers for X and Y, it allowed me to play from about level 184 without removing the integer scores....well, I also added a small delay(1) for every time a bike adds 500 to the score. This along with using the Fake 6 digit trick where instead of adding 500, I only add 50 and the extra 0 is just a placeholder to make it look like 500 which makes for smaller calculations until much later on in the game (if you can make it that far without having to continue).

 

At this point, doing a Fast game test (killing bikes using the 4,5, and 6 buttons to cheat kill them), I could get well over 210+ levels until I got tired of testing it....never blacked out.

 

Doing a Regular Play Test (actually playing the game, sometimes having to continue, no cheats), I got all the way up to level 184 and finally it blacked out. If that were a normal game, it would have taken over 3 hours to get that far. This version had less delay() codes for faster testing. I'm very good at the game and the best I've ever done without having to continue was, I think, 32 levels. That may have been when I only had 5 Areas to play. Now there are 10, I'm working on designing new ones now.

 

LATER for testing, I will hardcode the Score to like 60,000+ with Fake Digit it would display 600,000+ and try testing from there. Perhaps I can trap when the score wraps to 0 in case someone gets that far. I could display a message or something instead of displaying 0 or failing. At that point, I could force the game to stop calculating to prevent a crash or I could just code it to start over at 0.

Oh, and I got my first kid Play Test with my 4yr old twin nieces. They were having a great time playing the game. They LOVED the BONUS stage because they could collect all the "diamonds" (otherwise known as disks). They called them diamonds. I was really surprised since I really didn't think this was a game girls would even like. It actually kept their attention for a good 15-20 minutes....until my wife came in and said "Who wants to watch Frozen?".

[alekmaul]

If you are using Daniel's lib, all the things for managing score are included.

Take a look at getinput1 and this part :

 

/* === score_type : 2 unsigned values === */
/* gpstrsc.as */
typedef struct {
unsigned lo;
unsigned hi;
} score_t;
/* gpscoreN.as */
void score_reset (score_t *s);
int score_cmp_equ (score_t *s1,score_t *s2); /* compare score (equal) */
int score_cmp_lt (score_t *s1,score_t *s2); /* compare score (less than) */
int score_cmp_gt (score_t *s1,score_t *s2); /* compare score (greater than) */
void score_add(score_t *s, unsigned value); /* add unsigned value to score */
char *score_str(score_t *s, unsigned nb_digits);
void score_copy (score_t *score_source, score_t *score_destination); /* copy score */

Edited March 22, 2015 by alekmaul

[parkfun101]

Does that allow you to go up to a 6 or 7 digit score?

[alekmaul]

I think so, just take a look at bagman

[parkfun101]

Just a quick update, by popular demand (from Tarzilla), I've now added Grid Bugs! Here is level 11 that first displays these critters. I tried to make them look like the Arcade version and they only use tiles, NO sprites!

 

[parkfun101]

I think so, just take a look at bagman

Thanks Alekmaul, I'll have to do some tests using that score technique and the other one using all bytes. I think, for now, my code does what it needs and gives me the 6 digits I want. Each game is different though, so, I always like trying different techniques out. I looked at Bagman for CV on Youtube. Great Job!!!

[+Tarzilla]

 

Just a quick update, by popular demand (from Tarzilla), I've now added Grid Bugs! Here is level 11 that first displays these critters. I tried to make them look like the Arcade version and they only use tiles, NO sprites!

 

 

Awesome, thanks, I can sleep at night now!

[parkfun101]

I've finally added the Side Blaster weapon! To use the weapon, you have to touch one of the flashing circle looking icons. It basically creates a flashing beam on both sides of your bike which destroys everything in its way except the outer walls (it destroys inner walls as well!). On some levels, if you use this weapon, it can get into blocked off parts of the area. I may modify whether or not it destroys inner walls, but for now, I'll test it like this.

 

You have to be strategic when using this weapon because your bike is temporarily frozen while using it. That could be a good chance to block off your enemy while they are using it. The light beam also uses the color of the bike that creates it. This weapon can also be used to get you out of a maze if you're trapped.

 

This is the first day I've gotten to try this weapon out, but it's pretty fun so far . This is the last weapon/obstacle that I'll add to the game. Now I can start working on more levels, sound effects, and graphics.

 

Side Blaster (test level):

 

[parkfun101]

Game weapons and objects:

 

Just a note: Both the Power Boost and Side Blaster weapons can destroy inner walls. This will be used to make some fun bonus levels.

[Bodyshots]

Can I start making monthly payments for some copies now? Lol….