Jump to content
IGNORED

Road Rash pre-alpha on Jaguar at 30 fps


VladR

Recommended Posts

loop:

 

Vladr climbing a mountain.. looking out, seeing another one... going "oooh" then climbing back down before reaching the top and going up the new one.

 

Goto loop:

 

Better to attempt an ascent on the mountain rather than wallowing in the [sub-8-bit] puddle under the shadow of one!

 

 

 

 

Inevitably, the following quote comes to mind:

 

"Pigs prefer to wallow in clean mud, but if nothing else is available, they will frequently wallow in their own urine, giving rise to the notion that they are dirty animals"

 

-Marvin Harris

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

Any updates and plans to add gouraud shading to this?

 

I know music is the last bit of concern but those colours CRY for techno.

He just had surgery on his hand recently. He is taking a break right now but will be back on it soon. The 2 versions of the project I have are as far as he has gotten. I have been meaning to get around to recording video of the game running on my Jag, just so folks can see just how damn fast it gets. Maybe I will have time to record a video tonight. I will post it here when I do. (So many projects so little time)

 

I do hope he recovers soon and gets back on it.

 

Feel better soon Vlad

  • Like 4
Link to comment
Share on other sites

He just had surgery on his hand recently. He is taking a break right now but will be back on it soon. The 2 versions of the project I have are as far as he has gotten. I have been meaning to get around to recording video of the game running on my Jag, just so folks can see just how damn fast it gets. Maybe I will have time to record a video tonight. I will post it here when I do. (So many projects so little time)

I do hope he recovers soon and gets back on it.

Feel better soon Vlad

I hope Vlad feels better soon.

 

I spent the entire afternoon reading this thread in its entirety, and I want Vlad to know that I am truly impressed by the progress hes made on his 3D engine. The technical parts of this thread (when he started to post his notes regarding his engine) were a great read.

 

As for you recording a video of his engine running on real Jaguar hardware: that would be very much appreciated!

Edited by ColecoGamer
Link to comment
Share on other sites

- While my right hand hasn't recovered enough to be able to use mouse (still have to use left hand for the mouse), it's recovered well enough to sustain whole-day coding

- In the meantime, I've been coding a bit for Atari 800, as I could initially code for just few hours, and even that had to be spread out across whole day, which I wouldn't have patience to do for jag

 

- Gameplay-wise, in those 6 weeks, I haven't actually come up with a better idea than the latest one (I did come up with few others, but none as good), so looks like that space racing is the final candidate

 

- since I wrote a simple 6502 emulator in C++ last year, in about 10 hours of work, it's obvious I want to have the same for jag. The main advantage is intermixing of C with 6502 ASM, thus iterating through algorithms very quickly, especially due to Edit&Continue debugger feature of Visual Studio. I'm using DirectX for the graphics output.

- this weekend I wrote the core functionality of 68000 instruction parsing, namely the source/destination operands processing (with their addressing modes) and tested it on move / add instruction and now am ready to start implementing all other instructions

 

- since the codebase contains my 3D engine ported to 6502 ASM, including the C version, I'll reuse it and drive the 3D engine in C from 68000 assembler, yet all from within the Visual Studio environment, which I'm pretty sure is a very unique dev environment :)

 

The main purpose of this exercise is to be able to quickly experiment with gameplay/physics ideas in high-level C, inside Visual Studio on PC, instantly discard those that don't work, and only port to 68000 ASM the ones that work. Only the very final candidate will be transferred to jag for deployment and testing, saving giant chunks of excruciatingly slow debugging time on jaguar, not to mention the convenience of an integrated debugger in Visual Studio (showing all registers, variables and memory contents during debugging).

 

 

All of which will result in a better game. Which is what this is about.

  • Like 5
Link to comment
Share on other sites

  • 1 month later...

recorded from my cellphone, please forgive the shaky cam. :)

 

Not been around here for quite a while so haven't seen this. It looks impressive, is there a binary? If not, why not? Definitely share-worthy in that state. Good work, Vladr.

  • Like 3
Link to comment
Share on other sites

  • 1 month later...

Thanks. Haven't seen that particular one. I usually don't do full-transform on 68000, although I do a pre-translation stage for my 3D track segments on 68000 each frame, as it's happening in parallel to GPU/DSP/Blitter, and the relevant GPU code is not worthy of the precious 4 KB cache.

And, I gotta keep 68000 at least - somewhat - busy. At the moment, 68000 is really mostly idle - only doing the following at 60 fps:

- menus,

- H.U.D.,

- frustum culling,

- AI,

- input,

- camera

- enemy spawning

- game state management

- collision detection with track

- managing the GPU thread - poor GPU would be actually lost without 68000 !

- some sync with Blitter,

- ObjectProcessor functionality (OP List)

- some interrupts

 

So, it follows, that it's a better utilization of all HW resources, if it will lift some weight off GPU and do some per-vertex operations (like translation). As long as you hide behind the Blitter latency, you're good (just time it right)...

 

Some news ?

- Integrated audio code from the Atari samples into my codebase

- since I got the DSP code running in parallel with GPU/68000/Blitter, it was obvious I'd go and try to split certain stages of the 3D pipeline and move them onto DSP

- in the process above, I used the benchmark data I gathered in last 6 months (I have a very precise benchmark technique that allows me to measure how much time is wasted while Blitter is blitting scanline) and rearranged the pipeline stages in a quite different arrangement, so that the utilization of GPU is higher

- the result is 14.2% higher framerate (I measured it like, 10 times, as it was just insane), which is kinda incredible, at this stage of optimizations - and that's still without any help of DSP - this is merely a more optimal GPU code (e.g. 14.2% less down-time due to blitter drawing the scanlines)

- if you recall, previously I was getting 60 fps only at time-trial sections (e.g. no enemies/shooting). Now, I get 60 fps even with 3 enemies and music playing : )

- I can't wait to see once I put DSP to work on rendering (in a separate thread), what kind of 3D scenes will be possible

- I had to slightly upgrade 68000's thread manager (it was currently managing only GPU), as it's obvious, DSP will be very soon an another thread

 

- my 3dsmax -> Jaguar export toolset is done, so I can now instantly get any mesh from 3dsmax into the engine and one of next vids will showcase just that, as I got the first track done

- created a menu code and some art assets for main menu

 

- at start-up, you get to choose the resolution, in a simple menu, currently 6 resolutions, but as it's just a simple array, I will extend those options for all resolutions that jaguar supports

- I have recently refactored that code a bit, so now can actually change resolution dynamically at run-time (e.g. separate res for menu, separate for loading screen, separate for gameplay)

- there is one new resolution - I have a 768x200 centered framebuffer from within 1450x200 (e.g. the sharpest possible on jaguar). It's truly incredibly sharp, with the only drawback of the black bars at left/right (e.g. covers about 60% of the screen width, though the video chip displays only 720px), but it's an option, so it's worth trying out, and it's actually useable for certain things like loading screen or start-up logos, which are really incredibly sharp (it is, after all, a higher horiz. resolution than X360)

- you can actually play the full game like that - as GPU doesn't really care about jag's vid registers - it's still same 768x200 framebuffer as when it's stretched over whole screen (which brings me to another point - now that I give option of resolutions, I should do the same with aspect ratio - e.g. 4:3, 16:9, 16:10, 21:9))

- I almost got the full 1450x200 working via HDB2, but need to debug blank OP (OP barfs during HDB branching) from within 68000, and my OP debugging code is sitting on GPU, so I need to port that to 68000 first. Not a big deal - you basically press a certain joypad combo, and it replaces the OP list with debug one, yet preserving the contents of the old one (hence you can see what's going on with OP, even though the screen is blank)

 

- while doing some black magic (to retain 60 fps), I replaced the background 8-bit bitmap with 16-bit one (RGB 5-6-5), even though I doubled OP bandwidth - e.g. now it's 768x200x2 = 300 KB

- Of course, between two 150 KB framebuffers, and one 300 KB background one, that's 600 KB of RAM gone :)

- Thus, I am creating such content procedurally, at run-time (and load-time)

- Now that I have 65,536 colors for the background bitmap, I've started working on some pixel shaders (e.g. small inlined functions running per pixel). At the moment I have:

- planet atmosphere

- lens-flare

- Bloom postprocess (H/V kernel)

- Antialiasing (4 different kernels: 2x2 , 3x3 , 1x3, 3x1)

- Nebula shader - I change 3 parameters, rerun the function, and get a completely different looking nebula : ) It's not NASA quality, but looks good enough for me, and allows for basically infinite variety at run-time ; )

 

I have - somehow - mind-blowingly - never actually played with lens-flare shaders in HLSL while working on X360, so even though this is running off 0.01 GHz 68000 (faster to prototype in than GPU), there's a lot of exciting discoveries into how to get different shapes.

I'm getting - visually- veeeery close to the Mass Effect 1 - style lens-flare (the super-long horizontal one, across whole screen).

I am very excited that I managed to code the effect of the sun rising behind the planet and smoothly growing, as the sun's on-screen coverage gets larger, and it's real-time, and smooth. And since it's running in 65,536 colors, I can dynamically change both the shape, size and color - which totally beats having one or two pre-rendered bitmaps by an artist :)

For in-game rendered cutscenes, it's an absolutely awesome functionality :)

  • Like 5
Link to comment
Share on other sites

Dude that's awesome work... The graphics looks a little modular like it's following a path of some sorts rather than a modeled 3D environment... Kind of reminds me of "Checkered Flag"; despite the choppy frame rate, that game is probably one of the most open world 3D games to have a set of reusable 3D objects in a game. It seems like if the game wasn't in a loop with the race tracks, it could go on forever. You really got something on your hands there buddy; I really hope this engine comes out really solid for some really meaningful 3D gaming, which is a little lax these days as far as home-brewing. Great stuff man. :thumbsup: ;)

 

Some news ?
Do you know : https://www.catalase.com/optrot3d.htm

 

 

 

Out of curiosity I'd find a use for it... I'll take it.

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

Dude that's awesome work... The graphics looks a little modular like it's following a path of some sorts rather than a modeled 3D environment...

Yes, it's modular. The base track 3d mesh you see in vids was "modeled" in text editor, so it doesn't look fancy or anything. The final 3D mesh is created at run-time along a curve, by copying the base segment and connecting the vertices together.

 

I'm experimenting with creating a 3D curve inside 3dsmax and just importing the curve points - with the actual track 3D mesh only created at loading-time - this way the storage costs are minimized and a lot of tracks then can be fit under 2 MB. Eventually, even a curve could be computed at run-time, but I'm not sure that's actually worth my time, as the track points consume miniscule amount of memory (3 Bytes per point) so it's not worth the effort to optimize that particular piece of pipeline. At some point I gotta say that it's good enough...

 

It seems like if the game wasn't in a loop with the race tracks, it could go on forever.

Actually, it can. It's one of my built-in "unit test modes" - it loops forever so that I can test engine stability and precision - I usually keep it running overnight between builds and check it's still running fine in the morning.

 

Given my attraction to procedural content generation - I spent some time doing a research into what needs to be done to actually have an endlessly generated track at run-time (not just loading time) during gameplay - and this could be quite a fun mode - as you couldn't just memorize the track curves/hills/enemies. Since it would be randomized, each play-through would be unique.

 

Looks like an endless mode could be done in about a weekend, so it's actually worth spending time on.

 

You really got something on your hands there buddy; I really hope this engine comes out really solid for some really meaningful 3D gaming, which is a little lax these days as far as home-brewing. Great stuff man. :thumbsup: ;)

Thanks, it's been a lot of work, but it was very exciting and rewarding. No other PC/console coding comes close, as these days it's only about visual style / art assets.

 

This is the last place where every single assembler instruction matters :)

  • Like 4
Link to comment
Share on other sites

Well I'm certainly glad I sold you that 1mb 800xl for development. Amazing work, Vlad. Thanks for all the time you have put in.

Thanks, I'm really glad I had a chance to obtain the U1MB at the Portland expo ;)

 

Looking back, it looks like I spent over half of last 6 months working on the 6502 (rather than jag). That's mostly as a preparation for the upcoming EclaireXL boards (which are actually going to be shipped soon). There was a lot of research going into a much-faster 8-bit unsigned projection matrix, but I finally got it working last month. I'm spending next 2-3 months on jag again, but once EclaireXL boards arrive, I'll flip back to 6502 and create some demo.

 

 

If the quality is good enough, I'm hoping you would then publicly show the demo at the Portland expo in October on one of your machines (like you did with the MidiMaze) ?

  • Like 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

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