XB Racing

[1980gamer]

Looking great so far! I love the ability to choose a track, and the layout of these tracks is very nicely thought out. I used to play Sprint 2 http://youtu.be/RuPEoLkVwtI at the arcades back in the early 80's for hours, and this project brought back a lot of good memories (and some frustration as well ).

A few observations:

• Under plain XB without overdrive, the car does not respond well at all to the joystick. It worked fine with the first version of the game, so you must have changed your joystick polling timing since then. No issues with the compiled version.
• The car moves much slower when going up-down or right-left, and much faster diagonally. You might want to introduce a correction factor to the sprite speed for the orthogonal directions in order to even things out.
• A speed of 2, acceleration of 1 and turn rate of 15 seem to give the best results in the compiled version.
• Collision detection seems to work fine for me with the above settings, however I suggest reducing the "stuck" time at the track borders in order to enhance play. Also, I would add code to limit the sprite travel to the screen so as to avoid a fatal error and crash the program.

Excellent work! I can't wait to see how this game develops If interested, I would be happy to design an algorithm for opponent cars AI since racing against oneself is not ideal

1- Polling time... Yes, a few more commands have been added to the loop. I do not intend this to be an XB game at this point.

I may try to tighten up the code later, but I am in love with the compiler at this point....Simply because of collision detection ( coinc and GCHAR ) These do not work well or fast in XB.

2. Diagonals...Yup! This is easy to fix. I forgot about A squared + B squared = C squared....

3. Stuck in the walls... yup, you move out of the wall 1 pixel per cycle... could be 8 or more if you are between angled blocks.. I can adjust this easy too. But it should be a little slow...no?

4. I would love to add a computer car or 2... I had thought about it, but I have never created AI before.

For my PacMan ( mirror maze ) I simply use random-ness...with "attaction" weighted in on the outcome. I Wish that was better too...

 

I see this working for my current single screen courses. I was thinking of an LEMANS type course... Multi-screen track.

Ultimately, I'd like to create a global course that scrolls.... SOMEDAY.

 

 

@Sometimes... The collision is hard to make perfect. I am using dot position to character block gchar.

I tried making the walls wider as a truer representaion of the blocks. However, the dot to block conversion has some flaws.

The car uses the upper left corner pixel. I added an offset of 4 dots right and 4 dots down for more of... the middle of the car

but the text to dot formular still has drift. I tweaked this in XB and it was OK ( better ) however, I can not compile with the "drift" fix in place.

 

I would like to use the pixel perfect sprite to background code. But it would need to be a subroutine I could call. I only know basic

What a great enhancement that would be, I could be very creative with courses... I have to leave at least 2 blocks wide for every road right now.

 

I want to do more graphical menu "stuff" also. like the track selecting. Add Car selection with different profiles...

 

Be well....

Gene

[sometimes99er]

Maybe this one can help you. Should be pixel perfect.

 

! SETTING UP STUFF
100 call clear::call screen(2)
110 call color(1,2,2,2,13,13,3,14,14)
120 call hchar(24,1,40,64)::call vchar(2,32,40,46)
130 for i=0 to 8::call hchar(rnd*21+2,rnd*21+2,40,rnd*5+4)
140 call vchar(rnd*13+1,rnd*29+2,40,rnd*5+4)::next i
150 call char(33,"FFFFC3C3C3C3FFFF")
160 x,y=100::call sprite(#1,33,16,y,x)
! LOOP
200 call joyst(1,xd,yd)::y=y-yd/4:=x+xd/4::call locate(#1,y,x)
! PAINT CHARACTER AT UPPER LEFT SPRITE CORNER
210 call hchar(int((y-1)/8)+1,int((x-1)/8)+1,48)
! PAINT CHARACTER AT LOWER LEFT SPRITE CORNER
220 call hchar(int((y+6)/8)+1,int((x-1)/8)+1,48)
! PAINT CHARACTER AT UPPER RIGHT SPRITE CORNER
230 call hchar(int((y-1)/8)+1,int((x+6)/8)+1,48)
! PAINT CHARACTER AT LOWER RIGHT SPRITE CORNER
240 call hchar(int((y+6)/8)+1,int((x+6)/8)+1,48)
250 goto 200
! SPRITE IS PIXEL 0 THRU 7 (8 PIXELS) BUT TO GO FROM 0 TO 7 YOU ONLY ADD 7

[sometimes99er]

Here's another version.

 

! SETTING UP STUFF
100 call clear::call screen(2)
110 call color(1,1,1,2,13,13,3,14,14)
120 call hchar(24,1,40,64)::call vchar(2,32,40,46)
130 for i=0 to 8::call hchar(rnd*21+2,rnd*21+2,40,rnd*5+4)
140 call vchar(rnd*13+1,rnd*29+2,40,rnd*5+4)::next i
150 call char(33,"FFFFC3C3C3C3FFFF")
160 x,y=100::call sprite(#1,33,16,y,x)
! LOOP
200 call joyst(1,xd,yd)::y=y-yd/4:=x+xd/4::call locate(#1,y,x)
! GET CHARACTER AT UPPER LEFT SPRITE CORNER
210 call gchar(int((y-1)/8)+1,int((x-1)/8)+1,g1)
! GET CHARACTER AT LOWER LEFT SPRITE CORNER
220 call gchar(int((y+6)/8)+1,int((x-1)/8)+1,g2)
! GET CHARACTER AT UPPER RIGHT SPRITE CORNER
230 call gchar(int((y-1)/8)+1,int((x+6)/8)+1,g3)
! GET CHARACTER AT LOWER RIGHT SPRITE CORNER
240 call gchar(int((y+6)/8)+1,int((x+6)/8)+1,g4)
245 if g1+g2+g3+g4=128 then 200
250 call screen(16)::call sound(1,110,0)::call screen(2)::goto 200
! SPRITE IS PIXEL 0 THRU 7 (8 PIXELS) BUT TO GO FROM 0 TO 7 YOU ONLY ADD 7

The value 128 is 4 times the space character, ascii value 32 (4*32=128). Any character not being 32 will not return 128 (if ascii will be above 32 if not space). If you can write g1+g2+g3+g4 instead of my first g1+g2+g4+g4. Shame on me.

Edited January 11, 2014 by sometimes99er

[OX.]

This game is looking promising, any chance of 2 or 3 drone cars in there to race against?

 

Was also thinking it's too frustrating getting stuck on the edge of the track for so long - maybe once you've hit the edge and stopped have the car placed just away from the edge á la Super Sprint to make it more playable?

Edited January 10, 2014 by OX.

[1980gamer]

Sometimes99er--

Your demo has the same problem I am having.

If you look at the screen shot, the square is 49 pixels over the wall without hitting it. 7x7

If I move up 1 pixel or right 1 pixel, it will hit.

On the bottom or left...The collision is pixel perfect detection.

 

I will keep trying to adjust ... but it seems we have to make sacrifices?

 

I like the quick demo... I will use this to test! Much easier than a moving car!

 

Thanks for the help

Gene

 

 

[1980gamer]

Sometimes99er,

 

I see what you are doing... It looks like it should work! I don't know what is wrong yet?

But it is not working as intended yet....

 

Again, even if I get this to work as intended... it is still full 8x8 block edge detection, correct?

 

I would like narrower graphics... TI should have included a sprite to background coinc.

 

Well, I will keep playing...

[+Lee Stewart]

... TI should have included a sprite to background coinc.

 

They did—unless I miss your point. The CALL COINC() statement allows you to check coincidence between a sprite and a spot on the screen as well as between 2 sprites.

 

...lee

[sometimes99er]

Sometimes99er--

Your demo has the same problem I am having.

If you look at the screen shot, the square is 49 pixels over the wall without hitting it. 7x7

If I move up 1 pixel or right 1 pixel, it will hit.

On the bottom or left...The collision is pixel perfect detection.

WTF. The first program was tested also by another person. The second, when breaking is getting it right in the G1-G4 variables, so line 245 is wrong. I made an typo there. It shouldn't be g1+g2+g4+g4 but g1+g2+g3+g4 of course. I'll edit the above. Sorry.

 

[+Lee Stewart]

Here's another version.

 

 

 

! SETTING UP STUFF
100 call clear::call screen(2)
110 call color(1,1,1,2,13,13,3,14,14)
120 call hchar(24,1,40,64)::call vchar(2,32,40,46)
130 for i=0 to 8::call hchar(rnd*21+2,rnd*21+2,40,rnd*5+4)
140 call vchar(rnd*13+1,rnd*29+2,40,rnd*5+4)::next i
150 call char(33,"FFFFC3C3C3C3FFFF")
160 x,y=100::call sprite(#1,33,16,y,x)
! LOOP
200 call joyst(1,xd,yd)::y=y-yd/4:=x+xd/4::call locate(#1,y,x)
! GET CHARACTER AT UPPER LEFT SPRITE CORNER
210 call gchar(int((y-1)/8)+1,int((x-1)/8)+1,g1)
! GET CHARACTER AT LOWER LEFT SPRITE CORNER
220 call gchar(int((y+6)/8)+1,int((x-1)/8)+1,g2)
! GET CHARACTER AT UPPER RIGHT SPRITE CORNER
230 call gchar(int((y-1)/8)+1,int((x+6)/8)+1,g3)
! GET CHARACTER AT LOWER RIGHT SPRITE CORNER
240 call gchar(int((y+6)/8)+1,int((x+6)/8)+1,g4)
245 if g1+g2+g3+g4=128 then 200
250 call screen(16)::call sound(1,110,0)::call screen(2)::goto 200
! SPRITE IS PIXEL 0 THRU 7 (8 PIXELS) BUT TO GO FROM 0 TO 7 YOU ONLY ADD 7

 

 

The value 128 is 4 times the space character, ascii value 32 (4*32=128). Any character not being 32 will not return 128 (if ascii will be above 32 if not space). If you can write g1+g2+g3+g4 instead of my first g1+g2+g4+g4. Shame on me.

 

Unless I'm missing something (quite possible ), g1+g2+g3+g4=128 does not insure all four chars are ASCII 32 unless ASCII 30 and 31 are avoided (not allowed?) in the program.

 

...lee

[1980gamer]

Well, that fixes it! I was looking at the formulas rather than the simple math. Sadly, when I first read your demo at work, I noticed the g4+g4... but forgot all about it.

 

I will need a group of OR's if g1 <x or g1>y and g2<x or g2>y etc..

 

245 IF (G1<40 OR G1>64) AND (G2<40 OR G2>64) AND (G3<40 OR G3>64) AND (G4<40 OR G4>64) THEN 200

 

I need this change to "HIT" walls but "CROSS" check points.

 

I will add this now and see how it works :)

Gene

 

 

Vorticon- I am taking you up on your offer for AI cars!

 

Does anyone want to help with sound FX's? Maybe we can make this a real game!

Reading other posts, most people say the TI doesn't have enough driving games.

[+Vorticon]

 

 

Vorticon- I am taking you up on your offer for AI cars!

 

Sounds good I'll have something for you within a couple of day.

[1980gamer]

Latest updates...

Added screen EDGE check. You should not be able to leave the screen and crash the app now.

 

Added Sometimes99er's wall collision detection. Should be very accurate now.

 

Made hitting a wall a little friendlier..

 

TURBO--- pressing down on the joystick will give you 200 ticks of double speed.

You get 1 turbo boost. Thinking of adding bonuses.

 

Vorticon will be adding AI cars

 

Good night.

 

RCGL-C.zip

[sometimes99er]

Works better for me. Compiled, 2, 2, 15, track 3.

 

Perhaps and I guess especially for track 3, an option could be to move the checkpoints a bit inside the outer sprite limits. Adding and subtracting 1 (or maybe 2), like going from this (if I'm not getting something wrong)

 

1490 CALL GCHAR(INT((XP-1)/8)+1,INT((YP-1)/8)+1,G1)
1500 CALL GCHAR(INT((XP+6)/8)+1,INT((YP-1)/8)+1,G2)
1510 CALL GCHAR(INT((XP-1)/8)+1,INT((YP+6)/8)+1,G3)
1520 CALL GCHAR(INT((XP+6)/8)+1,INT((YP+6)/8)+1,G4)

to

 

1490 CALL GCHAR(INT((XP)/8)+1,INT((YP)/8)+1,G1)
1500 CALL GCHAR(INT((XP+5)/8)+1,INT((YP)/8)+1,G2)
1510 CALL GCHAR(INT((XP)/8)+1,INT((YP+5)/8)+1,G3)
1520 CALL GCHAR(INT((XP+5)/8)+1,INT((YP+5)/8)+1,G4)

[+Vorticon]

Drone AI: Here are my thoughts. When I design an AI, I usually write down the algorithm is plain language, then convert it to code.

 

1. Initialization of the drones:
   1. Each drone starts on a separate track
   2. Each drone is assigned a random speed, acceleration and turn rate, ranges to be determined
   3. Each drone is a separate sprite
2. Movement:
   1. The drones move by default in a straight line. Flags will be set up for each indicating vertical or horizontal movement. Up or Right is positive, Down or Left is negative.
   2. Each drone will check at regular intervals (to be determined depending on speed) a number of pixels ahead (number to be determined) for the track edge or another car. When an edge is detected, the drone will first check one unit of turn angle to the left. If still obstructed, then it will check one unit to the right. If still obstructed, it will now check 2 units to the left and right and so on until a clear path is found.
   3. Once a clear path is found, the drone will turn in the appropriate direction the required number of turn units, then resume going straight and back to 2(1).
3. Collision handling:
   1. Collision with another car: both cars stop and start spinning in place. The car which caused the collision will spin a bit longer than the other so as to allow that car to move away first. After that, each car will resume its original direction and speed. Back to 2(1).
   2. Collision with track border: Drone gets stuck for the appropriate delay, then tries successive 1 turn unit turns in the last chosen turn direction until a clear path ahead is found, then starts moving straight again. Back to 2(1).

Optional: Assign a turn severity weight to each turn in each track, and embed an invisible marker (non-printable character) in the track at the beginning of each turn to indicate the turn severity. This will allow the drones to slow down temporarily an amount proportional to the turn severity.

 

The above rules should create pretty decent "intelligent" drones which will try to avoid other cars and the track edge. Obviously, there is definitely some coding complexity involved here, so over the next few days I will try to create a simple demo and test this out. More to come.

[1980gamer]

--Sometimes99er

I like the change, it give the course a couple of pixel width and a truer visual collision.

 

--Vorticon

I like the path you are taking. It is beyond my wildest dreams! I think I can learn a lot from you.

 

I use "hidden" characters for check points already. What if we LINE the walls, 1 char deep all the way around?

The car can only turn left or right, so 2 chars are all that would be needed. On tight turns, I add the chars earlier?

 

Let me see if I can come up with a new course as described.

Gene

[OX.]

Will you be adding some static graphics on each track screen like tyres, oil drums, grass and mud etc?

[1980gamer]

Hi OX..

Additional graphics? Maybe? I am hardly an artist! Also, I am running low on available chars.

Well, I do not want to touch 0-9 or A-Z. A touch of color and graphics are possible though.

 

In this latest version...

Added track 5. This track has drone car directional info added.

Not visible to the player. But look at the MAP to see how I did it.

Is this what you had in mind Vorticon?

 

RCGL.rar is the dsk image

TEST.zip is the track magellan file.

 

RCGL.rar

TEST.zip

[sometimes99er]

I was reading 28 chars at a time. Adding "," to break up the long strings.

 

But I started that method to save every possible byte in my pacman game. Not a problem here....so far!

It appears to be faster to display 4*28 characters instead of only 28 characters at a time. Also it appears to take less bytes overall. Obviously the same with or without CPU Overdrive. Problem may be that it's not easy to list and edit from within the TI environment. Benefit of speed and size may be different with a compiled version. If Harry can tell then please do, I'm interested to know.

 

Guess you're not looking to save bytes just yet, but here's one starring me in the face. Unfortunately I'm not sure it works with the compiler. Go from this

 

2060 DISPLAY AT(5,5):"COURSE 1 BEST TIME:";TIME(1)
2070 DISPLAY AT(6,5):"COURSE 2 BEST TIME:";TIME(2)
2080 DISPLAY AT(7,5):"COURSE 3 BEST TIME:";TIME(3)
2090 DISPLAY AT(8,5):"COURSE 4 BEST TIME:";TIME(4)
2095 DISPLAY AT(9,5):"COURSE 5 BEST TIME:";TIME(5)

to this

 

2060 FOR I=1 TO 5
2070 DISPLAY AT(I+4,5):"COURSE "&STR$(I)&" BEST TIME:";TIME(I);
2080 NEXT I

Edited January 15, 2014 by sometimes99er

[1980gamer]

Hey Sometimes99er,

 

Yeah, not looking to save space yet.

 

The courses all start with the top row blank. So splitting the 6 data lines into 24 would let me save a bunch of space.

It also lets me right trim every row that doesn't go to position 28.

Again, for this game, not an issue at present. For pacman, I needed every single byte and I believe the compiler cares about DATA datum. LOL

 

2060 FOR I=1 TO 5
2070 DISPLAY AT(I+4,5):"COURSE "&STR$(I)&" BEST TIME:";TIME(I);
2080 NEXT I

 

this is a great change even without a space issue... I may add more courses, then I just have to change the TO value.

 

Thanks for all your help!

Gene

[sometimes99er]

The courses all start with the top row blank. So splitting the 6 data lines into 24 would let me save a bunch of space.

It also lets me right trim every row that doesn't go to position 28.

Yes, of course.

[+Vorticon]

Hi OX..

Additional graphics? Maybe? I am hardly an artist! Also, I am running low on available chars.

Well, I do not want to touch 0-9 or A-Z. A touch of color and graphics are possible though.

 

In this latest version...

Added track 5. This track has drone car directional info added.

Not visible to the player. But look at the MAP to see how I did it.

Is this what you had in mind Vorticon?

 

RCGL.rar is the dsk image

TEST.zip is the track magellan file.

 

 

Could you please post a zipped version of the file?

[unhuman]

I was thinking you may need more characters to let the robot cars know what the desired direction is... Otherwise they'll wind up spinning and going all kinds of crazy directions - which could make for a different kind of fun race!

Edited January 15, 2014 by unhuman

[unhuman]

Oh - and here's your zip file:

 

RCGL.zip

[1980gamer]

Thanks for creating the zip version.

 

I actually used the 8 directions the car can turn to help direct the drone car.

It may be to precise and need a little more random movement?

 

That is why I made a sample track. I will let Vorticon tell me what he needs to be successful.

[+Vorticon]

I was thinking you may need more characters to let the robot cars know what the desired direction is... Otherwise they'll wind up spinning and going all kinds of crazy directions - which could make for a different kind of fun race!

 

I don't think so, since the tracks themselves consist of straight lines and diagonals. There will probably be some zig-zagging when navigating curves, but I could add some logic to have the drones go straight when they reach the straight sections. It might mean adding additional hidden markers to indicate the start of these sections though. Also, some type of check needs to be made to prevent the drones from going the wrong way, particularly since some of the tracks have open intersections. More hidden markers maybe .

As you can seen, complexity can build up pretty quickly here, but it will really be fun to see how the drones behave in the end. I hope to sit down tonight and hammer some demo code. Since I am just testing the drone AI, I will only create a basic demo from scratch rather than try to incorporate the code into the main game, probably a basic track at first and one drone for ease of debugging, then gradually add further complexity. The end result should however be fairly easily grafted or adapted into the main game.