New Prototype - Driving thing

[PlaysWithWolves]

Yes that would be possible but its slightly different to what I mean. The road undulates up and down in one visible stretch before the horizon, which my thing can't do.

 

You may already be aware of this, but just in case: Here's how this guy tackled hills in his psuedo-3D racing game: http://codeincomplete.com/posts/2012/6/26/javascript_racer_v3_hills/

[Sporadic]

 

You may already be aware of this, but just in case: Here's how this guy tackled hills in his psuedo-3D racing game: http://codeincomplete.com/posts/2012/6/26/javascript_racer_v3_hills/

Yes thanks for the link. I have read that page many times before It has provided some good inspiration. I've had to code it quite differently though.

[PlaysWithWolves]

Yes thanks for the link. I have read that page many times before It has provided some good inspiration. I've had to code it quite differently though.

 

Hehe, I figured. Sometimes I get over-enthusiastic.

Let me know here or in PM if there's anything I can help you with.

[Sporadic]

 

Hehe, I figured. Sometimes I get over-enthusiastic.

Let me know here or in PM if there's anything I can help you with.

Many thanks for the offer

[Fredifredo]

I'm here

A SuperBurnout fan can help you

[PlaysWithWolves]

I'm sure lots of details need to be worked out with workflow, look-and-feel, palette, sizes, perspective lines and other things but this is just a proof-of-concept. Feel free to try it out if you wish. Of course, that pesky z-sorting would need to be addressed.

The idea is that this would be stackable horizontally at intersections or just to block the view behind it to hide that there's not a full city or town. It also should be stackable on the Z-axis to give it some depth (hopefully).

 

building_brick.bmp

[Sporadic]

I'm sure lots of details need to be worked out with workflow, look-and-feel, palette, sizes, perspective lines and other things but this is just a proof-of-concept. Feel free to try it out if you wish. Of course, that pesky z-sorting would need to be addressed.

The idea is that this would be stackable horizontally at intersections or just to block the view behind it to hide that there's not a full city or town. It also should be stackable on the Z-axis to give it some depth (hopefully).

 

building.png

haha excellent, that would look cool Thanks again.

 

I'm messing with object branches at the moment so i'm discovering what is possible before it falls on its ass. Big scenery like that might kill it but hopefully i'll know soon.

[PlaysWithWolves]

I keep forgetting this is programmed in a form of BASIC and not Assembly. It's amazing you're getting the FPS you do and seems a testament to the RAPTOR guys as well.

 

I think Super Burnout layered the sprites for their bleachers, and the 32X "Monaco" level of Slip Stream (which I never played) used it to great effect. They made a whole city level based on the idea, including a tunnel. You're probably familiar with all of this, but I'm playing catch-up.

 

Unfortunately, I don't know what "best practices" are for sprites. From what I can gather, it almost sounds like it's better to have multiple smaller ones than a single large.

[Sporadic]

I keep forgetting this is programmed in a form of BASIC and not Assembly. It's amazing you're getting the FPS you do and seems a testament to the RAPTOR guys as well.

 

I think Super Burnout layered the sprites for their bleachers, and the 32X "Monaco" level of Slip Stream (which I never played) used it to great effect. They made a whole city level based on the idea, including a tunnel. You're probably familiar with all of this, but I'm playing catch-up.

 

Unfortunately, I don't know what "best practices" are for sprites. From what I can gather, it almost sounds like it's better to have multiple smaller ones than a single large.

yep, BASIC all the way. You're right, it is a testament to Raptor and Reboots work.

 

I get the impression a single large sprite would be better than many small ones because it's less objects to process but i don't really know for sure and it could be certain things will suit this "engine" better than others.

 

Once I have played around more and found the limitations of what this can handle, then we will know max sprite sizes, quantity, colour depth etc etc.

[+CyranoJ]

To be honest it's not the object count that is killing this, its the scaling.

 

Despite what everyone thinks, the jaguar is not very quick at scaling bitmap objects, more than a handful and the OP will choke on it's own pixels. I'd say maybe try 4 or 5 different sized ones that are pre-scaled and jump-size them will get you a lot more performance.

[Sporadic]

To be honest it's not the object count that is killing this, its the scaling.

 

Despite what everyone thinks, the jaguar is not very quick at scaling bitmap objects, more than a handful and the OP will choke on it's own pixels. I'd say maybe try 4 or 5 different sized ones that are pre-scaled and jump-size them will get you a lot more performance.

Interesting. I had thought about trying this idea. I'll give it a spin!

[Sporadic]

To be honest it's not the object count that is killing this, its the scaling.

 

Despite what everyone thinks, the jaguar is not very quick at scaling bitmap objects, more than a handful and the OP will choke on it's own pixels. I'd say maybe try 4 or 5 different sized ones that are pre-scaled and jump-size them will get you a lot more performance.

You are correct sir.

 

I've just turned off scaling and was able to push the scenery objects closer together before any tearing appeared. Much more than before. This is with them all defaulting to their full size even at the horizon.

 

Going to go create mipmaps now.....

[+CyranoJ]

You are correct sir.

 

So this isn't a 'what if?' thread then

[F.L]

hello

nice road rengine !

me too i'd like to make a 2d road game !

i have already make one game in basic (with the help of lou gorenfeld example)

and i'd like to port it on rb +

here is a pic of the engine road code working with qb64

and a pic of the same running to test with rb+ :

can you tell me if it could work with rb+ ? for the moment i have just tested it

with plot because i can craw lines but i think i could use a sprite of each line (60 sprite- is it not too much ?)

and the re is a second problem, i dont become to do the zmap for changing the color of line, i dont know why it dont works...

can you see the code and say if its possible, or can you explain how work your prototype to me ?

thanks in advance !

here is my code for rb+:

' road engine for RB+ by F.L from lou gorenfeld example : http://www.gorenfeld.net/lou/pseudo/

CONST RoadLines = 66
dim SpeedScroll = 5
CONST RoadY = -1 'arbitrary
CONST ResX = 320
CONST ResY = 200
CONST PlrLine = 8 '  ??
'DIM ZMap(RoadLines) AS SINGLE
dim horizon = 134
dim ScreenLine
dim WidthStep
dim A
'dim b
dim LINE

' Initialize ZMap
'FOR A = 1 TO RoadLines
    'ZMap(A) = RoadY / (A - (ResY / 2))
'NEXT A

' Normalize ZMap so the line with the player on it is scale=1 (or would be
' If we had a player sprite )  ' ??
'b = 1 / ZMap(PlrLine)
'b = b * 300 '                    height of road strips
'FOR A = 1 TO RoadLines
    'ZMap(A) = ZMap(A) * b
'NEXT A

dim positionX

DIM X AS SINGLE
DIM DX AS SINGLE
DIM DDX AS SINGLE
DIM HalfWidth AS SINGLE
DIM SegY AS SINGLE

'TexOffset = 100
SegY = 40 'RoadLines
DX = 0
DDX = -.05 ' angle of turn

'           main loop

DO

 
 HalfWidth = 160 '  width of road
    WidthStep = 2.3 '  inclination of the straight road

    '                               keyboard  input

    'IF _KEYDOWN(19712) THEN DDX = -.05
    'IF _KEYDOWN(19200) THEN DDX = .05

    'IF _KEYDOWN(20480) THEN SegY = SegY + 1
    'IF _KEYDOWN(18432) THEN SegY = SegY - 1

    '                           limits of the turn

    IF SegY < 0 THEN SegY = 0
    IF SegY > RoadLines THEN SegY = RoadLines

    ' Set up the frame

    X = 160 ' center of road

    DX = 0 ' try 1 or -1 to change the side the road

    ScreenLine = ResY - 1

    FOR A = 1 TO RoadLines
    '    IF (ZMap(A) + TexOffset) MOD 100 > 50 THEN
    '        GrassColor = 10
    '        RoadColor = 7
    '    ELSE
    '        GrassColor = 2
    '        RoadColor = 8
    '    END IF

        ' Draw the road
  'LINE (X - HalfWidth, ScreenLine)-(X + HalfWidth, ScreenLine), GrassColor
  colour 2
  plot (X,ScreenLine)
  
        ' left grass
        'LINE (0, ScreenLine)-(X - HalfWidth, ScreenLine), GrassColor

        ' right grass
        'LINE (X + HalfWidth, ScreenLine)-(320, ScreenLine), GrassColor

        HalfWidth = HalfWidth - WidthStep
        ScreenLine = ScreenLine - 1

        IF A > SegY THEN
            DX = DX + DDX
        END IF

        X = X + DX

    NEXT A


 
    ' Wrap positions (fractional):

    'TexOffset = TexOffset + SpeedScroll
    'WHILE TexOffset >= 100
    '    TexOffset = TexOffset - 100
    'WEND

    ' background display

    'LINE (0, 0)-(320, horizon - 1), 9, BF

    '  others display

    'COLOR 15, 9

    'LOCATE 1, 1: PRINT "esc to exit"
    'LOCATE 2, 1: PRINT "up-down :  do the curve"
    'LOCATE 3, 1: PRINT "left-right : change the direction"
    'LOCATE 7, 10: PRINT "turn to the"

    'COLOR 4, 9
    'IF DDX = -.05 THEN LOCATE 7, 22: PRINT "right"
    'IF DDX = .05 THEN LOCATE 7, 22: PRINT "left"

    'IF _KEYDOWN(27) THEN END
 
    '_LIMIT 50
 delay(1)
    '_DISPLAY 
 vsync

LOOP

Edited January 4, 2018 by F.L

[VladR]

 

but i think i could use a sprite of each line (60 sprite- is it not too much ?)

 

 

When I was working on the prototype of RoadRash from C, one of working codepaths for the road that I implemented, was using the bitmap approach - I had 100 bitmaps in the OP List.

 

That was from C, without any GPU-based OP List processing, like rB does.

 

Unless the rB backend is beyond horribly inefficient (possible, not sure how likely, as I don't use it) it should be faster than crude C and have no problems updating some 60 bitmaps in the OP List.

 

 

Hell, even a rudimentary, non-optimized 68000 code can do about 28-30 bitmaps within the short vblank period, so 60 should not break a sweat on GPU, given that GPU has 444,300 cycles available at 60 fps.

 

 

 

As for your code example - you have to understand the Lou's tutorial thoroughly. I would recommend spending a day/weekend with it on PC first, debugging through it, so fully understand each line of code. It'll save you a lot of debugging later down the road...

[Sporadic]

Yes there were some commands added to help with this.

 

The most helpful will be powaset. This allows you to pass an array of values and it'll update all the objects at once. This is much faster than doing them individually.

 

So for example you could have an array of xpos[60] and update those values in your code. Then pass that array to powaset with sprite_x and it'll update all those objects. You can use this for all object properties (have an array for each).

 

Alternatively you can use the blitlist functionality and draw with the blitter. There is an example for this in rB. If you are going to use that then I recommend reading about the Jaguars Blitter first. I have some resources I can link you to later but they aren't hard to find online.

 

I can provide more information but I'm busy at the moment but wanted to reply

 

I also recommend looking up how to do integer math and ditch those SINGLEs. They are slow. Or create a load of lookup tables

Edited January 4, 2018 by Sporadic

[VladR]

I've implemented 4 different algorithms for my RoadRash prototype. Here's a quick summary of the first 3 (since you are starting out), to consider/experiment different approaches:

 

1. ObjectProcessor - based

- you have 60 scanlines in the OP List that you need to manage

- performance: is limited only by speed of updating the OP List, drawing of road is essentialy ~free (basically system-wide bandwidth)

- at the cost of memory, this approach should leave you with most available performance available for other tasks (hills,AI,input, HUD)

 

2. Blitter - based

- you draw each scanline manually with a Blitter call (con: learning experience)

- performance: you must wait after each scanline, so either you waste majority of performance waiting or figure out something else to compute in parallel while blitter is spinning, as you will hit the 30/60 fps threshold very quickly.

 

3. CPU/GPU - based

- you draw each scanline, pixel by pixel, via explicit write-to-memory instruction

- performance: up to 51.2 Mil pixels/second (or 28,444 each frame at 60 fps) from GPU

- since your road is just 60 scanlines, on average, you draw 60*320/2 = 9,600 pixels, it's doable at 60 fps

 

The 4th one is a parallel-processing hybrid (read my thread for more info) that I don't believe is available to you via rB, but the above 3 should be, although - obviously- at varying sub-optimal performance characteristics.

[ggn]

Only the first two options are viable in rb+. The GPU is devoted to raptor running, doing all the frame-to-frame stuff of managing the objects, their movements, collisions and so on.

 

For someone that's just starting out I'd suggest taking sporadic's route: first making a working but slow road using objects, then speeding it up using powaset. Then if more speed is required, go for blitter.

 

Also, by all means start first using floating point numbers but consider moving on to fixed point as soon as possible. The floating point library rb+ uses (PML) is there just for reference, not performance.

 

Now, if you do mean to take the GPU road then you've outgrown rb+ - godspeed and all!

Edited January 4, 2018 by ggn

[VladR]

That's why I put CPU/GPU there. Even if he has access only to CPU (68000), it's still a great learning experience to find out just how many pixels can you brute-force through, and therefore why the OP/Blitter is fundamentally the way to go.

 

Also, for initial prototyping, nothing is safer and simpler than DrawPixel (xp,yp, color).

 

Does rB expose framebuffer directly via some array ? Can you do something like FrameBuffer [(yp*320)+xp] = color ? Or perhaps equivalent of *ptrFrameBuffer = color ? Or only a DrawPixel () -style function ?

 

As far as floating-point goes, I usually recommend having a first reference version that works even if at 0.1 fps (but keep it, forever, for reference, even if commented out, as it is very easy to get lost in incremental refactoring), using floats, then work your way up from there, replacing equation by equation with integers.

 

If he hasn't worked with fixedpoint, then that's too much to get up&running at first time - unknown road algorithm, fixed-point, blitter, rb, ...

 

Depending on how the blitter array is handled in rB, the second option might be fastest and most flexible (plus, almost zero memory costs, especially compared to first OP version) - assuming the GPU is issuing the blit commands, then it does not matter that GPU is stalled between calls, as 68000 is available to do all other game processing in parallel- hence 60 fps is totally doable and basically effortless.

[F.L]

thanks for the help, but my knowledge of coding is low, so i dont understand all

i will try a very little road game with a few lines to display and i will see if it works

[VladR]

How about you start with lowest possible road first and go from there:

- straight road (no curves, hills),

- 45 degree angle, so you don't have to handle floats,

- ScanlineLength = 100

- each scanline is thus 1 pixel to the right of previous one (XposNew = XposLast + 1)

- each scanline is 2 pixels shorter than previous one (ScanlineLength = ScanLineLength - 2)

- Single color (no texturing) - just grey color

 

Then, you can add alternating scanline colors (e.g. every 10 scanline you use color1, and then switch to color2)

 

Then, you can add perspective via simple LookUpTable SegmentLength [32,16,8,4,2,1] - meaning you have 6 segments and each segment will have number of scanlines equal to SegmentLength [idxSegment]

 

Then, you can add the middle lane.

 

Then you can add curves via another table : xpOffset [idxScanline]

 

Then hills.

[sh3-rg]

hot tips:

 

listen to sporadic & ggn

look here: http://www.extentofthejam.com/pseudo/

Edited January 5, 2018 by sh3-rg

[F.L]

hello

i have adapted for rb+ the ancient example in basic of lou gorenfeld and the curves are working

you can move it and change the curve with up down, right,left

with this little example, making a simple game is possible, but without hills.

each line is a sprite and it runs at 60 fps

the .bas and the gfx are in the zip

but there is a problem, all the lines have the same color, i dont become to change the colors of lines

because i dont understand something in the translation of lou gorenfeld example in rb+....

with qb64 it worked fine

normally the result must be like this :

look at the code , i have putted comments where it's wrong and where i dont understand...

i hope all this will help someone to create a little 2d road game on jaguar

see ya and good night

2Droad.zip

Edited January 8, 2018 by F.L

[ggn]

One thing that stood out immediately:

 

        ' IF  ( ZMap[A] + TexOffset ) MOD  100 > 50  THEN ' this original code dont work with rb+ !
		IF  (( ZMap[A] + TexOffset ) /  100 ) > 50  THEN ' i have done this but i dont know if its good 

Nope, that's not the same! The modulo (MOD) will give you the remainder of a division while the division (/) will give you the result. As an example: 5/2=2.5 while 5 MOD 2=1 (because 2*2+1=5).

 

Rewriting the first line using bcx's syntax (docs\bcxhelp.chm is your friend) gives us:

 

IF  mod ( ZMap[A] + TexOffset , 100 ) > 50  THEN

and that makes the road flash now - progress!

 

 

Now, for my next trick:

 

'b = ZMap[PlrLine] / 1 ' in original code it was " b = 1 / ZMap[PlrLine] "     but it crash rb+ ,why ??

I tried the original and it didn't crash. Also it made the top line a different colour than the rest! Hooray! Perhaps you have set it to 0 when you tested and it gave a divide-by-zero?

 

 

Another observation:

 

dim b
...
b = 1 / ZMap[PlrLine]

b is declared an integer and then we ask it to do floating point math - that can't end well! You need to dim it as single I suppose. Or you might get away with it, since the code that uses b is:

 

b = 1 / ZMap[PlrLine]
b = b * 30	' height of road strips
FOR A = 1 TO RoadLines
    ZMap[A] = ZMap[A] * b
NEXT A

this could be rewritten as

 

FOR A = 1 TO RoadLines
    ZMap[A] = (ZMap[A] * 30) / Zmap[PlrLine]
NEXT A

however don't do that yet as it's just an optimising step - just make it run ok first and then think about speed.

 

 

I don't want to dive in further as I'd have to read Lou's article more closely. But this will probably end up with me rewriting everything from scratch! What I would suggest instead is to print out the values of ZMap from your qb64 code and try to match them in rb+ as well. Then I'm sure you'll find out what's wrong there!

Edited January 8, 2018 by ggn

[F.L]

thanks for the help !

now the code is like the original example

but the color of lines dont swap...its strange ?

and

IF mod ( ZMap[A] + TexOffset , 100 ) > 50 THEN

make the loop slow...

however, the method for moving the color of roadstripes was just a quick example of lou gorenfeld

there is many methods to do.

look what it is possible to do with this same code :

http://www.youtube.com/watch?v=u44uLqybwOc

i have modified the .bas to show you a simple line with a quick but bad method

(normally, the speed of stripe depend of his distance)

i have done all this a few years with the same codes

for the moment, i have no time , i hope someone will wan to do something with all this

2Droad.zip

Edited January 8, 2018 by F.L