Vampire Flatshading Experimenting

[DamienD]

Well, must say that you've definitely taken this thread way "off topic" with your engine / Vampire / other console discussions VladR...

Anyway, too tired now but will deal with tomorrow

So, what do you want your "new thread" to be titled?

[Dunny]

Originally Posted by DamienD

So, what do you want your "new thread" to be titled?

"Remaking Virtua Racing" or "Let's not bother with what made Outrun great, and replace all that with polygons" perhaps?

[VladR]

Originally Posted by amiwolf

For real? That isn't what their FPU wiki states:

https://wiki.apollo-accelerators.com...pollo_core:fpu

I guess the documentation might need an update.

Well, I have literally just found out that you can issue an FP op every cycle.


But FP is a 5-stage pipeline and each op has different latency when the result is actually available:


1 cycle latency: fabs, fneg, ftst
6 cycle latency: fadd, fsub, fmul, fcmp
9 cycle latency: fdiv


This obviously means a proper scheduling is required.


What is unclear to me right now is if the Pipe1 can execute other integer ops in the meantime or if it's locked to currently executed FP ops.


Because if that was the case, then using FP is a really bad idea from a performance standpoint. Imagine doing few ops and waiting 50 cycles for a result...


I guess I'm going to stay with my Integer rasterizing pipeline.

[VladR]

Originally Posted by DamienD

Well, must say that you've definitely taken this thread way "off topic" with your engine / Vampire / other console discussions VladR...

Anyway, too tired now but will deal with tomorrow

Sorry about that.

Originally Posted by DamienD

So, what do you want your "new thread" to be titled?

Truthfully, it's all going to be experimenting initially.


Perhaps "Vampire Flatshading Experimenting" ?

[VladR]

Thanks for creating separate thread

[VladR]

I think I'm done with my initial 24-bit RTG experimenting in 320x240 as I have some basic routines (transform,clip,scanline texturing) working in emulator.

This is a simple test scene for my Radiosity lighting, probably best useful for a FPS shooter game.

The top part of screen shows the lightmaps (only four fit there), that were computed at run-time based on form factors. This currently handles 2 lights, but can easily supply 32 (or more) lights if it was needed.

The axis-aligned walls would lend themselves best to a grid-based dungeon crawler.

Or a Wolfenstein could look interesting with such lighting...


I can now start porting my flatshaded StunRunner-style game finally into the vasm project. Hopefully I will have something running by end of week.

[roondar]

I don't actually own a Vampire, but it will be interesting to see where you end up.

[eXeler0]

Originally Posted by VladR

8><-----------
Of course, no worries. This is more of an exploratory exercise at this point.
Just make sure the polygons are quads and there are no polygons you cannot see (e.g. delete backface polys). There are some restrictions in 3dsmax how the quads must be edited and which modifiers - I don't recall exactly ATM, but generally it must be Editable Poly and you use Quadrify otherwise 3dsmax doesn't put 4 vertices into the OBJ file (and still breaks it down to triangles, even though in your scene it shows as a quad).

Yes, in 3dsmax the older EditMesh always works with triangles regardless if you make edges visible or invisible. In a way thats the beauty of EditMesh, but for quads, for sure, Edit Poly, however Quadrify will only try to create quads by making some edges invisible. With such low poly assets its probably better to model quads by hand and make sure they are flat within that quad.

Btw, I'm half done with a race car model I started on yesterday night.
Do you have a ballpark figure for how many quads you wanna aim for?
I was thinking that the player-car would be somewhat like Virtua Racing, maybe some more detiails here and there, but the other cars would be a lower level of detail. If the performance would allow it you could simply use the higher detail level for all cars, and the lower poly as LOD for all other cars when they aren't close to the camera.

Hopefully I can send you a finished quad model within a couple of days for testing.

Cheers

[VladR]

The opponent cars - given that we have 512 MB RAM, I reckon I'd go for pre-rendered sprites (say, at 5 angle increments) but still retain the flatshaded lowpoly look so they match (and don't stick out). I'd rather put the performance into environment. It's a lot of work to match the various angles with the bounding box of the bitmap, but it's doable. Then, we could have 8 cars on track in view without killing framerate.

Player car would be fully rendered, for sure.

As for environment - why don't we try to shoot for VirtuaRacing complexity? I know it's not a fair comparison, given how many DSPs the Sega Model 2 has and we only got one CPU (though at 85 MHz).

The draw distance in VR can be quite huge - I've counted 40 road segments in one screenshot. That's around 1,000 triangles / 500 quads per frame, since each segment is usually around 12 quads (from what I can see at screenshots).

A very quick / rough estimate of such scene complexity (mainly scanline loop) is:
- 12 quads per row (e.g. "columns" on the world grid)
- 40 rows
- ~160 scanlines (usually) - out of 240 as usually ~60% of screen height is covered in 3D scene (but mountains do cross that threshold)

160*12 (columns) = 1,920 scanlines

I'm glad I did that computation. ~2,000 scanlines / frame I could pull from Jag's GPU easily.

Of course, the player car and all the other props (trees/boxes/etc.) will raise that number, but it's very reasonable for an environment.

The transform cost would be 12*40 = ~500 vertices to transform. That might prove challenging, but view distance can be changed at run-time easily.

[eXeler0]

Howdy, @ValdR, I sent you a pm, with a link to a low poly race car model which you can freely play around with. I did it all quads (unless I missed something).

Let me know if it works for you.

For some screenshots, check the VirtuaRacing gallery again. Added 3 screengrabs from max vieport at the bottom of the gallery.
http://www.exretro.com/galleries/seg...ing/index.html

[eXeler0]

@VladR PMd link to some screenshot of a test-track mesh ;-)

[VladR]

Originally Posted by eXeler0

@VladR PMd link to some screenshot of a test-track mesh ;-)

Awesome, I should be soon able to load it in emulator (and few days later give you a build to try it yourself).


Last two days I've been working on porting and optimizing the Quad Rasterizer (~500 lines of ASM code, but worth the effort), which reduces the number of scanlines processed by 50% compared to triangles by traversing the quad from top scanline to the bottom one and switching between the edges as needed.





I got two version now:
- Integer
- Floating Point


Both work completely with CPU's registers without touching the RAM (except for pixel fill, obviously) so they should be pretty darn fast (though still have some CPU pipeline bubbles)


Attached is my test scene (with some slight shading). 32 quads, but take 1,315 scanlines with quads (or it would be 2,630 scanline with triangles).

[grond]

Nice! Btw, you can get rid of the mouse arrow by setting the mouse sprite to a completely transparent sprite in your startup code.

[VladR]

Originally Posted by grond

Nice! Btw, you can get rid of the mouse arrow by setting the mouse sprite to a completely transparent sprite in your startup code.

Yeah, I'm keeping it for now as for debugging (printing 100 values on screen) I often use the other (non-waiting) codepath that is waiting for the mouse press.

[VladR]

So, for max performance, I have two versions of quad rasterizer:
1. No clipping checks per scanline.
2. Per-scanline clipping checks.

This decision happens right before rasterizing.

I have ditched the old fixed-point version of the clipped version and implemented the floating-point ops. Since there are 4 separate codepaths (1-pass, 3-pass and two 2-pass), the combinatorial complexity with clipping shot through the roof, so I'm about 75% through right now.

Especially the top screen edge wreaks havoc with various scenarios. There's 14 already and probably few more I haven't thought of. Testing that with 100% confidence might prove really problematic.

I'm thinking of implementing a generic version that will introduce two more checks per scanline (the primary reason for having separate versions in the first place) but would be a single generic code covering all 14 versions.

Handling triangles is really simpler by an order of magnitude. But you don't often get the chance to improve performance by a factor of 50%, so it's worth it

[Photon]

Originally Posted by eXeler0

Amiga ppl are used to lower FPS in many games :-) We used to think doom clones were perfectly playable at 15 fps

Why not take a poll and find out how the Amiga users you speak for feel about that... could be enlightening

[VladR]

Originally Posted by Photon

Why not take a poll and find out how the Amiga users you speak for feel about that... could be enlightening

You got the Delorean prepped & fed with 3 jiggawatts ? I think I could come up with a slightly better use of all that energy.


Because no poll in 2020, after everybody and their dog was exposed to constant 60+ fps on recent consoles, could remotely accurately describe actually how forgiving we all were [across all platforms] about the abysmal framerates 30 years ago.


Doom here is actually a great example. With every PC upgrade (between me and friends) it seemed like it couldn't possibly be faster or smoother, but when I got the DX4-80 MHz it still became more fluent and ridiculously fast.


We just never experienced that kind of framerate before, where every single pixel on screen became redrawn in a 3D game.




I'm pretty sure I played Wolfenstein at sub-10 fps on my 80386 and it was fine.




When Descent was released, the framerates were quite horrendous, forget about 15 fps, some rooms fell down to 3-5 fps, yet I still enjoyed it tremendously.
Speaking of Descent, I recently found a YT vid of it at what appears to be sub-10 fps on V4 (though at 960x540). After 5 minutes, it is fine and you just get used to it.


Of course, for my racing game, I will need to adjust scene complexity & scale down pretty visuals for at least 20-30 fps. We'll see...

[Dunny]

He's right - how many of us played FA/18 Interceptor on stock A500s back in the day? And loved it, and were't really bothered about the framerate?

How many would like that same framerate today?

[VladR]

I'm going to give one more -very prominent- example from Atari 8-bit.

BallBlazer. Everybody thought it was running at 60 fps.

But recently, somebody was examining it in Altirra and found out that thing was merely locked to 20 fps.

But, because it didn't randomly skip frames and it didn't move through the world fast enough (only enough to keep the per-frame delta to 1 px), it fooled a whole freaking planet to thinking it was 60 fps.

If the movement speed was slightly slower, it would have been exactly as smooth at 15 fps (as long as per-frame delta is 1 px).

I made same tests - slowed down the racing speed on Jaguar, and I couldn't really notice myself the difference between 15 and 60 fps, as the per-scanline delta was still the same one pixel.

One could make a turtle racing game that would completely smooth at 6 fps, because of the super slow speed.

[DamienD]

Just saw this on Indie Retro News: Formula Retro Racing - Could this be the next Virtua Racing game?

http://repixel8.com/formula-retro-racing