fast 3d rendering/Kabuto's magic
category: general [glöplog]
How do I start learning to optimize software renderers? I want to make a wireframe game that runs fast, how do I learn this black magic? I saw Kabuto's work and I'm inspired, but I've read that that stuff wouldn't work in a game, does anyone know why?
The first step is to start and try something. Have you taken that step yet?
I'm going to start learning 6502 ASM as much as I can
Mike Abrash’s black book is an entertaining read for sw rendering optimizations. Here is some talk about optimizing line drawing http://www.jagregory.com/abrash-black-book/#chapter-35-bresenham-is-fast-and-fast-is-good. You may need something more 6502 oriented though.
here's more to read from our former member jix of titan (who we miss)
https://jix.one/pushing-polygons-on-the-mega-drive/
https://jix.one/pushing-polygons-on-the-mega-drive/
Quote:
software renderers?
stop it, please
get help
Quote:
Quote:software renderers?
stop it, please
get help
Consider this a warning about your behaviour - this level of toxicity is pissing me off and I'm probably not the only one.
Confirmed.
Gargaj feel free to delete my account at any moment
kabuto also wrote a bit about how he improved my approach (that neoman linked) in the middle of this document: https://docs.google.com/document/d/17pX_PS5uXSWoaS71JurC-DSKIV8ZAzlaP4o1jXbJ9CA
but yeah it requires lots of preprocessing, so it's not really usable for anything dynamic
but yeah it requires lots of preprocessing, so it's not really usable for anything dynamic
Quote:
I'm going to start learning 6502 ASM as much as I can
That said, i suggest a kindof backwards approach. Use your favourite high level language and knock up a bresenham line drawer. Then make a rotating cube using simple sinus tables and simple projection. Make this work simple and elegant and try to understand every detail of it. Once you are there, try converting it into 6502. Expect to fail hard, it will be slow and shit. Find out why. Optimize. Iterate a few times.
good luck :)
Yeah I'd wager the optimization process is same regardless of platform:
- Write algorithm
- Optimize algorithmically (= finding mathematical ways that are faster)
- Optimize circumstantially (= choosing your use cases based on the dataset)
- Optimize to platform (= make code fit the architecture by using the right amount of CPU-memory tradeoffs, cache reads, etc.)
- And THEN you optimize the actual code itself and see if you can win cycles.
- Write algorithm
- Optimize algorithmically (= finding mathematical ways that are faster)
- Optimize circumstantially (= choosing your use cases based on the dataset)
- Optimize to platform (= make code fit the architecture by using the right amount of CPU-memory tradeoffs, cache reads, etc.)
- And THEN you optimize the actual code itself and see if you can win cycles.
I repeat: The first step is to start and try something.
If you haven't started and tried something, then reading advice on forums is completely meaningless.
If you haven't started and tried something, then reading advice on forums is completely meaningless.
my own approach to this, when I was relearning amiga programming, was close to what groepaz said.
1. Make a dot plotter
2. Make a 2D rotator with the dot plotter
3. Extend to 3D rotation (and perspective) with the dot plotter
4. Extend to 3D line drawing vector
5. Extend to hidden line vector
6. Extend to Filled surface vector
So as others have mentioned, Start simple, with something you can grasp, and extend it further.
1. Make a dot plotter
2. Make a 2D rotator with the dot plotter
3. Extend to 3D rotation (and perspective) with the dot plotter
4. Extend to 3D line drawing vector
5. Extend to hidden line vector
6. Extend to Filled surface vector
So as others have mentioned, Start simple, with something you can grasp, and extend it further.
btw: there is a good read here: An introduction to vector-based graphics on the Commodore 64
With examples in 6502 assembler.
With examples in 6502 assembler.