Log In  



Cart #dbuf_test-2 | 2024-06-07 | Embed ▽ | License: CC4-BY-NC-SA
9

This is mainly a tech demo for a 3d engine with a depth buffer. This is not finished, but I wanted to share it.

TODO:

  • Optimisations maybe?
  • BSP - currently model faces aren't sorted, so concave models will work weirdly. The depth buffer is only for interactions between models.
  • Maybe lower the resolution for better performance?
  • Some sort of culling?
  • Better use of depth buffer resolution, make it more linear maybe?

(The depth buffer works with the use of colour tables, in a few passes. If anyone wants more detail, I can provide it.)

Oh yeah, controls:
WASD: Move
QE: Up/Down (relative to look dir)
Arrows: Rotate camera

Z/C: Toggle depth rendering

Thanks @freds72 and @Maeve for advice on the memory issue, I hope it's gone once and for all! (Memory still rises rapidly, so I'll look into what could be causing that too)

9

I wish tline3d’s performance costs were on a per-pixel basis instead of a per-call basis. (EDIT: Hey maybe you should stop calling set_draw_target ONCE PER TLINE????!! HELLO?! -Me from the future) Currently, drawing 2 short lines is more performance intensive than drawing 1 long line. This means the goal of 2.5 screens full of tline3d per frame is almost impossible to reach. Additionally, I’m not too sure why the program is running out of memory, and it’s worrying that it messes up the Picotron os when it does (it cleared my spritesheet!!!)

well done!

As for performance, you have huge avenues for optimizations!
To name a few:

  • stop calling functions during core rasterization loops (lerp...)
  • stop "fetch"ing pod each frame (that explains the out of memory I suspect)
  • ...

Oh, is pod causing out of memory? I shall have to look into that. I did do a test earlier by just replacing the values to tline3d with all 1. It dropped the cpu usage by roughly a third, so it wasn't too big on my priorities. I shall try that though. Thanks!

(Updated cart) Awww, It was going so well until the web player ran out of memory. I thought i fixed that, and it's annoying that stat(0) returns 0. Still, I think it ran longer before crashing. It also runs better, although the triangles do have seams now.

Ahh I've also had that problem where running out of memory will delete cartridge data. I haven't looked into it much but does the new anywhen thing help with retrieving lost data? That's how I've understood it

Also I haven't looked at your code yet but one thing that gave me a small performance boost while working on my own 3d renderer was to not update the rendering of a triangle until its rotation or position had changed by some visible threshold from the previously rendered frame (which would be some kind of function of the size and distance from camera, I forgot how I implemented it exactly, it's been a month or two since I've touched the project)

I should definitely make some kind of performance profiler that shows how long each function takes to execute. I'm also at a dead end for the memory bug. Hmmm.

I had a similar issue with it running out of memory frequently with the piconet explorer when I was creating new large userdata every frame. I believe I instead did something to the effect of creating a new one as little as possible and then overwriting past data, but that only works if it is consistently the same userdata dimensions/size I think.
1

@Maeve Ohhhhhhhhhhh, That must be it! Thanks! I'll re-use the buffers for the models, it shouldn't be too hard.



[Please log in to post a comment]