Log In  

Cart #41579 | 2017-06-13 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

I've finally managed to get a clean, 3d wireframe engine up and running. It does backface culling but otherwise is as plain as it comes.

Working through the maths and pulling together from various sources was a pain as writing a software renderer is a bit of a lost art form with D3d/OpenGl doing all the maths for you these days.

So I thought people might appreciate a simple example to start from.

THis doesn't do any camera transforms - the camera is at 0,0 starting down the z-axis.

P#41580 2017-06-13 09:11 ( Edited 2017-07-19 15:20)

Oh, use the arrow keys and zx to rotate the cube on the 3 axis and s/f to move the cube along the z axis.

I don't have clipping planes implemented yet so you can move the cube behind the camera and have it go crazy

P#41581 2017-06-13 09:12 ( Edited 2017-06-13 13:12)

I have one big optimisation left on the table. I'm recomputing the polygon normals from scratch every single frame rather than making them part of the model data and transforming them with the rest of the model during the world transform.

Now I just need some model data for spaceships from Elite and I'll be good to go!

P#41601 2017-06-14 05:08 ( Edited 2017-06-14 09:08)

If you're just doing backface culling with the normals, you can replace that completely by just checking if you are drawing the triangle in the wrong order (clockwise vs. counter-clockwise).

P#41602 2017-06-14 07:38 ( Edited 2017-06-14 11:38)

I was planning on experimenting with flat shading as my next step so I'll keep them in for now - but if I abandon that I'll remember your tip

P#41603 2017-06-14 09:12 ( Edited 2017-06-14 13:12)

Cart #41612 | 2017-06-14 | Code ▽ | Embed ▽ | No License

Found a source of Elite spaceships, also 'extended' engine to cope with arbitary polygons rather than just triangles

P#41613 2017-06-14 12:21 ( Edited 2017-06-14 16:21)

Found a source of Elite spaceships

I never knew how badly I wanted a PICO-8 demake of Elite until right this second. Oh, man. Oh, man.

Nice work on the wireframe rendering code.

P#41617 2017-06-14 13:53 ( Edited 2017-06-14 17:53)

Cart #41644 | 2017-06-15 | Code ▽ | Embed ▽ | No License

Experimenting with solid fill. Next stop light shaded polys and then I'll consider a z-buffer

P#41645 2017-06-15 17:16 ( Edited 2017-06-15 21:16)

Cart #41659 | 2017-06-16 | Code ▽ | Embed ▽ | No License

Now with flat shading - the code quality has degredated somewhat but this has made me I realise I have some kind of mirroring issue as it looks like my x-axis inverted from what I expect.

P#41660 2017-06-16 05:54 ( Edited 2017-06-16 09:54)

Right, my next step is to tidy up the code to create a generic concept of a mesh and a model, a mesh being a descrition and a model being a game world object.

Then once I can have multiple models in the world I either have to do full on z-buffer or simply draw models in z-order (I will be going with option number 2!)

Then I extend the code to allow every polygon in a model to have it's own colour/colour gradient (so the engine exhausts on the elite models can be red for instance) and then I might call it a day on this.

P#41661 2017-06-16 07:52 ( Edited 2017-06-16 11:52)

Oh, I suppose I should do the camera transform as well before I can say it is complete

P#41662 2017-06-16 07:55 ( Edited 2017-06-16 11:55)

If you want to see me play around with this then follow me on Twitter @twitonatrain to see hilarious bugs and the like

P#41700 2017-06-16 15:56 ( Edited 2017-06-16 19:56)

Zomg - I've just realised that my projection matrix is transposed. This explains every subtle (and really not subtle at all) bugs that I have!

P#41814 2017-06-20 16:09 ( Edited 2017-06-20 20:09)

Cart #42412 | 2017-07-12 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

The Big Mega Massive Update

Codes commented, has a positionable camera, lovely dithered shading a choice of solid, wireframe or vertex rendering.

Input 1 rotates a tree, input 2 rotates the camera.

Hopefully this code should be relatively easy to understand.

P#42413 2017-07-12 16:35 ( Edited 2017-07-19 10:22)

Cool! The dithering and shading looks nice. Were you able to get it up to the benchmark you wanted?

Do you have plans for a game using it, or just making the rendering engine?

P#42416 2017-07-12 19:36 ( Edited 2017-07-12 23:36)

Very cool! If you're looking to optimize your triangle fill function, check out this thread: https://www.lexaloffle.com/bbs/?tid=28317

P#42417 2017-07-12 20:55 ( Edited 2017-07-13 00:55)

I'm planning on doing a walking simulator with it, taking a walk through the woods.

Regarding speed ups (which the engine still needs) I'm exploring two avenues. My dithering code precludes me from getting the cheap and easy and non intuitive rectfill speed up and I think a full z buffer (so per pixel setting) would be too slow so I'm thinking about scanline rendering with an active e edge table. I'm also investigating options for speeding up drawing static geometry (going to work out the code complexity/size of BSP trees).

P#42422 2017-07-13 02:08 ( Edited 2017-07-13 06:54)

Ah ha, just spotted a dumb arse inefficiency in my code, I'm constantly recalculalting the gradients for the lines in my scan line function. I can just calculate them once and pass them. Right, lets see how much faster the code is once I pull that out.

P#42504 2017-07-15 07:22 ( Edited 2017-07-15 11:22)

Experimenting with different triangle fill functions. Given that I am sticking with my dither I am limited in how much I can optomise but it is absolutely insane that switching from LINE to RECTFILL speeds up my engine from 1800 triangles a second to 4050 triangles a second.

Shame I'm stuck with MEMSET based methods.

P#42564 2017-07-17 07:33 ( Edited 2017-07-17 11:33)

just in case you missed it, there's this thing you should know about rectfill:
that might be fixed in next update (?)

P#42565 2017-07-17 10:39 ( Edited 2017-07-17 14:39)

Good to know. I'm sticking with MEMSET due to wanting dither so my preference would be for MEMSET to take 0 CPU and everything else to be massively increased CPU usage ;)

P#42567 2017-07-17 11:11 ( Edited 2017-07-17 15:11)

New triangle renderer knocks 0.13 off of CPU usage when rendering the reference cherry at the cost of occasional pixel gapping in triangle edges.

I deem this... acceptable.

P#42573 2017-07-17 16:36 ( Edited 2017-07-17 20:36)

Here is one of my more awesome looking failures in trying to optimise

Cart #42574 | 2017-07-17 | Code ▽ | Embed ▽ | No License

P#42575 2017-07-17 16:39 ( Edited 2017-07-17 20:39)

Two questions:

1) Are you still doing arbitrary polys, as when you were doing line-based drawing? I notice your first filling demo had a cube made of triangles. Are you tessellating n-gons to triangles for rasterization? I keep meaning to try writing a renderer that does native n-gon rasterizing, assuming the n-gons have convex, coplanar boundaries. It's more logic for following edges down the screen but potentially saves a lot of per-tri and per-span overhead.

2) Could you optionally call rectfill() when your fill value is 11,22,...,FF? On average, half of your polys will be solid. If you start doing 1/4 and 3/4 dithering too, then you'd only need memset for the even lines of 1/4, both lines of 2/4, and the odd lines of 3/4. Similar savings but more gradient options.

P#42585 2017-07-18 00:00 ( Edited 2017-07-18 04:04)

1) I'm turning n sided polygons into triangle fans to draw, logically try remain n-goms right up until the polyfill call. Next on my list of things to learn is get my head round scan line rendereing and see if that is as fast. I am cheating as I'd don't depth sort the triangles before drawing, only the models, so concave models have 'hidden poly' over drawing like the stalk and leaf of the cherry.

2) That's a very good idea but I think given that an new pico version might radically change rectfills performance I will stick with 100℅ memset for now and wait and see .

P#42587 2017-07-18 02:15 ( Edited 2017-07-18 07:48)

The final though I've had is maybe sprite blitting is fast and I could do shading via blitting sprites? Anyone tried that?

P#42588 2017-07-18 03:47 ( Edited 2017-07-18 07:47)

I ran three bits of code that filled the first row of the screen through my benchmark. These are the cycle counts for each:

--- ---------------------------------
  6 RECTFILL(0,0,127,0)
384 SSPR(0,0,128,1,0,0)
 69 MEMSET(0x6000,0,64)

So, uh, nope. And the non-scaling SPR() works in units of sprites, so that's also gonna take too long.

P#42600 2017-07-18 12:22 ( Edited 2017-07-18 16:22)

Hey, @Felice can you run that same benchmark for RECT() and LINE()?

Also, can you tell me how to get those figures for cycles in pico-8? I've just been using stat(1), but this seems more accurate than that.

P#42602 2017-07-18 13:26 ( Edited 2017-07-18 17:26)


Basically I have a for loop that's tuned to run for exactly one second without anything inside. Other testing showed that the overhead of the for loop is one cycle per iteration, so every second added to the run is one more cycle added to each iteration, and thus one more cycle for the code inside the loop.

My stuff's a little more complex than this, but this is the basics of what you need to test the cost of code:

local __t=time()
for __i=0,0x40.afda,0x.0001 do
  <insert code here>
print("cycle count = "..flr(__t-0.5))

Oh, and line(0,0,127,0), which is the line()-equivalent of the other code I tested, comes in at 134 cycles.

Edit: Just saw you wanted rect(), not the rectfill() I already did. A 128x1 rect() comes in at 122 cycles. 128x128 comes in at 238.

P#42604 2017-07-18 15:47 ( Edited 2017-07-18 20:27)

That's a super handy test rig Felice. Thanks for that.

The rect and rectfill cycle counts are just so wacky.

P#42615 2017-07-19 06:20 ( Edited 2017-07-19 10:20)

Yeah they are. I think it's a programmer's old friend at fault: the off-by-one error. The API has both xyxy and xywh calls, and I imagine there are a few call costs calculated on the wrong assumption.

P#42619 2017-07-19 11:20 ( Edited 2017-07-19 15:20)

So cool! I don't know anything about 3D so this is amazing!

P#134750 2023-09-22 01:20

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2023-12-01 23:29:50 | 0.056s | Q:60