New Prototype - Driving thing

[Sporadic]

Hi all,

 

Thought i'd share a little progress on a separate prototype i've been playing around with.

 

Only spent a few hours messing around so far, just needed a break from AstroStorm.

 

You can guess from the screenshot what it is.

 

There is no "forward" movement yet, that's probably next.

 

Just use Dpad to move the road direction around to see the road curve and uphill/downhill (this would be automated in a game by the track layout - you would move your car).

 

 

 

 

road.abs

Edited August 23, 2015 by Sporadic

[sh3-rg]

GGN is going to laugh when he sees this, I showed him this page I was looking at (Lou's Pseudo 3D page) and I was mumbling on about how I'd like to make something like that and how I might go at it.

 

Really impressed, it looks so tidy, I can just imagine the backdrop bobbing to the horizon, feels so slick - you have to keep doing stuff with this, loads of games could be possible once you get it moving.

 

[Sporadic]

GGN is going to laugh when he sees this, I showed him this page I was looking at (Lou's Pseudo 3D page) and I was mumbling on about how I'd like to make something like that and how I might go at it.

 

Really impressed, it looks so tidy, I can just imagine the backdrop bobbing to the horizon, feels so slick - you have to keep doing stuff with this, loads of games could be possible once you get it moving.

 

Haha excellent Nice coincidence there!

 

I know the page you mention. Ive had something like this running on Android before but I could not think how to go about it in rb+.

 

It's not as quick on the real Jag as the emulator but im sure optimisations can be made.

 

No clever tricks here. It's a static image, full road with perspective (what you see when you start it up).

 

There are then 150 1px high sprites which each point to sequentual lines in the image. These simulate scanlines.

 

Before the "game" starts it works out the speed of each line in x and y. The further away it is, the faster it moves.

 

Then in the main loop when you move, it just iterates the 150 sprites and sets the xadd and yadd to that lines speed.

Next frame the speed is zeroed again.

 

There might be more efficient ways but I dont know them lol.

[ggn]

Want movement controls NAO!

[ggn]

Seriously, totally wicked stuff!

[Sporadic]

Want moment controls NAO!

Was thinking about switching the CLUT for each scanline to similate movement. Kind of colour cycle it.

[sh3-rg]

Thanks for the explanation, I was going to ask but you already offered it

 

Did you try out a chunkier version with double lines at all to half the object count?

 

Was thinking about switching the CLUT for each scanline to similate movement. Kind of colour cycle it.

 

I don't have the experience of you guys when it comes to this stuff, but I know CLUT flipping or colour cycling are cheap and effective Before you mentioned that, I was thinking of an animated road texture, having it as an auto-animating raptor object and adjusting the rate of animation to simulate faster and slower speeds... maybe RMotion could help here - it's something I need to look into. but yeah, colour cycling would be much more controllable than that, flipping through CLUTs might work but sort of feels less controllable after a quick thought... loading different sets of 16 into the CLUT sections might also work as a slightly less hassley and more hands-off way of going through the colours... I just make 2x2 sprites for assets.txt to give me a range of colour palettes quickly.

 

Looking forward to see where you take this.

[Sporadic]

I had thought about doing half the resolution (chunkier scanlines) but was going to fall back on that if too slow.

 

I was also thinking that animating the road could be a way to do it but clut switching might be easier. (I'm no artist) . Depends if it adds much slow down.

The benefit of animating the road would be that it could look textured and the stripy lines could be removed. But I do like the Outrun look

[sh3-rg]

Yeah, that stripy road has a great feel to it.

[ggn]

Like sh3 mentioned I was actually discussing some methods on how to draw a road and then bam! you land a binary .

 

Anyway my guess is that you're probably doing a ton of rsetobj per frame, which gets slow very fast (rsetobj wasn't really built for performance, just a quick and nasty hack left over from the original raptor basic). We came up with two ideas to speed this up:

 

a) figure out the addresses you want to rsetobj and lpoke them instead (which is a bit hardcore unless you know the inner workings of raptor a bit)

b) write a command that takes an array of values and move them in consecutive objects. For example, want to set the x value of 150 objects? Load them in an array and then pass the pointer to the function, as well as the attribute you want to change and starting object. Something like powarset(pointer to values, start object, offset, no of objects to change).

 

If b sounds like something that would help you I can fix something up for you.

[sh3-rg]

[Sporadic]

Like sh3 mentioned I was actually discussing some methods on how to draw a road and then bam! you land a binary .

 

Anyway my guess is that you're probably doing a ton of rsetobj per frame, which gets slow very fast (rsetobj wasn't really built for performance, just a quick and nasty hack left over from the original raptor basic). We came up with two ideas to speed this up:

 

a) figure out the addresses you want to rsetobj and lpoke them instead (which is a bit hardcore unless you know the inner workings of raptor a bit)

b) write a command that takes an array of values and move them in consecutive objects. For example, want to set the x value of 150 objects? Load them in an array and then pass the pointer to the function, as well as the attribute you want to change and starting object. Something like powarset(pointer to values, start object, offset, no of objects to change).

 

If b sounds like something that would help you I can fix something up for you.

That sounds f@#king awesome! I would definately be interested to check that out.

 

As I've said, this is just a mess around at the moment, so no rush or anything.

 

But having said that, I think a POWARSET command would be an excellent addition anyway!

[ggn]

That sounds f@#king awesome! I would definately be interested to check that out.

 

As I've said, this is just a mess around at the moment, so no rush or anything.

 

But having said that, I think a POWARSET command would be an excellent addition anyway!

You might want to check latest repository head for powarset(spr_index, offset, no_of_times, array_of_values) (all parameters longwords). Completely untested of course!

 

[EDIT]Wanted to call the function powaset to save you some typing But since sh3 went into the trouble and made a whole pic to illustrate powarset, powarset it is!

 

P.S. I really don't mind doing some quick hacks like these to people that go into the trouble of doing some stuff and then hit a performance roadblock. So don't be shy to ask for improvements if you see that some things can be done better!

Edited August 24, 2015 by ggn

[+CyranoJ]

Now that is really nice

 

Electraglide.... Outrun.... Road Blasters..... lots of possibilities. Just don't make Fatal Run 64 or Desert Bus 64!

 

And, again, as ggn said above - likewise if you think RAPTOR needs something. As long as the person requesting stuff is actually doing something I'll genuinely listen to suggestions. I won't even entertain things for people asking for more and doing nothing.

[+CyranoJ]

Then in the main loop when you move, it just iterates the 150 sprites and sets the xadd and yadd to that lines speed.

Next frame the speed is zeroed again.

 

There might be more efficient ways but I dont know them lol.

 

OK, if you just want to move for one frame, then don't use xadd, yadd at all.

 

Just add/subtract the value from the current x/y position, and remove the code that zeroes the xadd/yadd.

 

[edit]

Actually thinking about it, that might need RGET and RSET... (Ahhh BASIC, why can't you do the simplest assembler thing without jumping through hoops?)

 

Hmm I suggest an RMODOBJ command that applies a difference to an existing value

Edited August 24, 2015 by CyranoJ

[Sporadic]

You might want to check latest repository head for powarset(spr_index, offset, no_of_times, array_of_values) (all parameters longwords). Completely untested of course!

 

[EDIT]Wanted to call the function powaset to save you some typing But since sh3 went into the trouble and made a whole pic to illustrate powarset, powarset it is!

 

P.S. I really don't mind doing some quick hacks like these to people that go into the trouble of doing some stuff and then hit a performance roadblock. So don't be shy to ask for improvements if you see that some things can be done better!

Excellent! I will give it a spin, thank you.

 

If I think of anything then I will definitely say, cheers.

[Sporadic]

Now that is really nice

 

Electraglide.... Outrun.... Road Blasters..... lots of possibilities. Just don't make Fatal Run 64 or Desert Bus 64!

 

And, again, as ggn said above - likewise if you think RAPTOR needs something. As long as the person requesting stuff is actually doing something I'll genuinely listen to suggestions. I won't even entertain things for people asking for more and doing nothing.

 

Point taken, don't use the digits 6 and 4 in the title lmao

 

Thank you also for the offer, I will let you know if I think of anything. Probably the only thing i've come up against so far that might help would be to be able to set the origin for scaling operations in the object file. Sometimes it definitely helps if the origin is the middle of the sprite rather than in a corner. This way I wouldn't have to work out the new x position after the object is scaled at runtime to keep it central (otherwise it scales out to the right etc).

 

Cheers

Edited August 24, 2015 by Sporadic

[Sporadic]

 

OK, if you just want to move for one frame, then don't use xadd, yadd at all.

 

Just add/subtract the value from the current x/y position, and remove the code that zeroes the xadd/yadd.

 

[edit]

Actually thinking about it, that might need RGET and RSET... (Ahhh BASIC, why can't you do the simplest assembler thing without jumping through hoops?)

 

Hmm I suggest an RMODOBJ command that applies a difference to an existing value

RMODOBJ isn't a bad thought. Then we could just say "move left 1.5 pixels".

 

I used xadd and yadd because in AstroStorm I started off the other way and found things quite jumpy when over 1 pixel. Some of these road "scanlines" need to move more than 1 pixel in a frame and it just seems smoother. I will admit, I didn't try just add/subtracting the x/y as you said though. I could track the line positions in an array, that way I would only need an RSET. Plus, if using the new function from ggn I could just POWARSET the whole array

 

Will have to play around more.

Edited August 24, 2015 by Sporadic

[ggn]

OK, if you just want to move for one frame, then don't use xadd, yadd at all.

 

Just add/subtract the value from the current x/y position, and remove the code that zeroes the xadd/yadd.

 

[edit]

Actually thinking about it, that might need RGET and RSET... (Ahhh BASIC, why can't you do the simplest assembler thing without jumping through hoops?)

 

Hmm I suggest an RMODOBJ command that applies a difference to an existing value

Done, although I didn't like the name, so I named it powadiff instead .

[+CyranoJ]

 

It actually looks like one does!

[Sporadic]

Done, although I didn't like the name, so I named it powadiff instead .

lmao love the name. Going to name all my variables at work today starting with Powa...

 

You are a machine, thank you

[Sporadic]

You might want to check latest repository head for powarset(spr_index, offset, no_of_times, array_of_values) (all parameters longwords). Completely untested of course!

Hi,

 

I just tried to give these 2 new commands a go and get a build error.

Translating .bas file to C... 
 
Compiling C code... 
C:\Rik\basic\PROJECTS\road\build\road.C: In function 'void basicmain()':
C:\Rik\basic\PROJECTS\road\build\road.C:206:46: error: 'powadiff' was not declared in this scope
Build error! 

Translating .bas file to C... 
 
Compiling C code... 
C:\Rik\basic\PROJECTS\road\build\road.C: In function 'void basicmain()':
C:\Rik\basic\PROJECTS\road\build\road.C:206:46: error: 'powarset' was not declared in this scope
Build error! 

I copied my project folder into the new basic\projects from the latest version. I then copied a rapapp.s out of an existing example (not one of the failing ones) and into my project folder.

 

I'm calling it like this;

powarset(startline, R_sprite_xadd, 150, xpos)

and have also tried;

powarset(startline, R_sprite_xadd, 150, *xpos)

where startline is an int pointing to the first sprite and xpos is an array[150] of ints. I wasn't sure how to pass the pointer for the array of values to the new commands, I tried both the above. Not sure if that's related to it not compiling.

 

Thanks

[ggn]

Did you copy rbasic.h from the include folder too?

[Sporadic]

Did you copy rbasic.h from the include folder too?

I copied my project into the new rb+ download. Then copied the rapapp.s from one of the tutorials into my project. So it should have been using the include fokder fron the git download.

I will double check though.

[Sporadic]

Did you copy rbasic.h from the include folder too?

ok, might be my bad. I just checked the rbasic.h in my basic folder and its the 1.2 version (not today's master one).

 

So I think I downloaded master, came across the 3 non-compiling projects, changed to 1.2 to test that, still found the 3 non-compiling projects, reported to you, then tried the new powa commands.

 

Forgetting to go back to master!!!!

 

So i'm sorry, looks like my issue. I've not retested yet, but my rbasic.h looks correct now.

 

Cheers

Edited August 24, 2015 by Sporadic