Jump to content
IGNORED

New Prototype - Driving thing


Sporadic

Recommended Posts

Cool project!

 

I'm flying pretty blind here, so caveat emptor, but I thought I'd attempt a tree to try (if you want). 96x96 LBM 15-color palette w/transparent color. LBM is inside the ZIP.

 

Excellent. Thanks for the contribution!

 

I'll give it a go once I get the scenery running :)

 

There will more than likely be caveats to what will work. For example, the width will probably be more like 64px but none of that will be finalised until I get things rushing past the car etc. I can't say for sure yet.

 

Cheers :D

Link to comment
Share on other sites

New update! It was getting boring with no scenery.

 

Now it's slightly less boring i guess....

 

 

 

If I make the scenery too close together then I get tearing as there is too much overlapping.

Also, there is only some basic accounting for z-order so occasionally you might see something overlap, deal with it :P

 

Added "loading" screen so you have something to watch while it builds all the lookup tables. (Yes it is doing something in the background, i'm not making you wait for no reason).

 

Edit: Press C for handbrake (slow quicker).

I'll probably move accel/brake to A and B too.

 

P.s. Thanks to PlaysWithWolves for the trees. :thumbsup:

PowaRoad151115.abs

Edited by Sporadic
  • Like 6
Link to comment
Share on other sites

I probably sound like a scratched record by now but this looks very good even at this early(ish) stage! Did you eventually use branch objects? Otherwise you'll probably gain a massive amount of bus time back.

No branching. I've no idea how it works or how to use it!

Link to comment
Share on other sites

I didn't realize that LBM wasn't standard; I assumed it was because Protector SE uses it.

 

Some with shadows:

Excellent thanks. I will check them out.

 

I'm just using 4bit bitmaps (.bmp). I can open the .lbm files but i would just convert them to .bmp. The first palette entry is the transparency (as you had already).

Link to comment
Share on other sites

I didn't realize that LBM wasn't standard; I assumed it was because Protector SE uses it.

Well, LBM was more common about... 20 years ago I think? :) Anyway, the rb+ asset importer uses bmp files exclusively, without compression. I never had any request from people to support any other formats so my guess is everyone's fine with it.

 

(Plus I don't want to add any more file parsers for the moment. Or have to use something like Imagemagick which I have absolutely no clue if I can distribute with rb+ so then I'd have to ask people to download it on their own which could lead to "interesting" bugs/side effects and ARGH PLEASE NO THE PAIN MAKE IT STOP PLEASE)

Edited by ggn
  • Like 1
Link to comment
Share on other sites

Well, LBM was more common about... 20 years ago I think? :) Anyway, the rb+ asset importer uses bmp files exclusively, without compression. I never had any request from people to support any other formats so my guess is everyone's fine with it.

 

(Plus I don't want to add any more file parsers for the moment. Or have to use something like Imagemagick which I have absolutely no clue if I can distribute with rb+ so then I'd have to ask people to download it on their own which could lead to "interesting" bugs/side effects and ARGH PLEASE NO THE PAIN MAKE IT STOP PLEASE)

 

Haha, no worries. LBM was actually a problem for me when helping Carl, because the closest Photoshop can get is IFF (as far as I know).

A couple months ago I snatched-up some Humble Bundle 2D game-making assets which included the program, Pro-Motion. It saves in the Deluxe Paint LBM format, among some others.

Edited by PlaysWithWolves
Link to comment
Share on other sites

The main unfortunate difference is this "engine" only supports hills going up and down. Most other similar engines handle dips in the road or distant hills as can be seen in that video stillframe.

 

Perhaps that'll come to this but not any time soon unless I get a brainwave.

 

Something is better than nothing though!

Link to comment
Share on other sites

The main unfortunate difference is this "engine" only supports hills going up and down. Most other similar engines handle dips in the road or distant hills as can be seen in that video stillframe.

 

Perhaps that'll come to this but not any time soon unless I get a brainwave.

 

What about your suggestion of a second parallax layer for the distant hills? In the Road Rash video, the back layer moves faster horizontally than the front layer, but they always stay on the same vertical plane.

Link to comment
Share on other sites

 

What about your suggestion of a second parallax layer for the distant hills? In the Road Rash video, the back layer moves faster horizontally than the front layer, but they always stay on the same vertical plane.

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.

Link to comment
Share on other sites

Ah. I thought you were referring to both the undulating track and the very distant hills.

 

BTW, I just happened upon this thread where the Super Burnout programmer chimed in about tricks he used (including branches):

 

IIRC, on the code side, everything was developped with the DSPs, nothing with the 68000, except just boot and VBL sync.
Because there was only 4 KB of memory on the GPU, I was hot-swapping portions of the assembly code, modules by modules, trying to reuse as much as possible the cached memory (something that is also done commonly on PS3 SPUs).
Everything worked well together and I'm pretty sure I still had CPU cycles left even with more than 1000 sprites on the screen.
By the way, I was displaying the 1000+ sprites on Jag with a trick on the display-list.
The Jag was a killer in 2D (ok, at that time icon_wink.gif, but the only downside was that if the display list contained too many sprites, it actually ate bandwidth on the sprites to display,
creating sometime this wobbling effect on some line (due to the fact the jag didn't have screen buffer but was diplaying everything on the fly, nice design to save expensive memory
but with some constraints icon_wink.gif
So the way I resolved that was to actually use the branches of the display list, by having 3 levels of branches I was actually able to split the screen in 8 horizontal bands of 30 pixels or so.
Then I just had to fill each of the sub-display lists separatly, thus I just had 125+ sprites per display list, but 1000+ total displayed on the screen.
That way each horizontal line had almost full bandwidth to display the sprite.
The nightware was on the GPU side though, every single sprite had to be split in pieces to be placed on the proper horizontal band with the propoer offset initialized. Sometime sprites like bosses could be split over the whole 8 bands. Everything was displayed with that, even the multiple level of tiles for the background.

Edited by PlaysWithWolves
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...