I think the point is more that triangles are a kind of basic primitive - you can build any filled polygon from triangles - however, a dedicated quad renderer will always be faster than rendering the equivalent two adjacent triangles.
But consider that such a quad renderer will almost certainly be expecting convex quads, i.e. exactly one pixel span per scanline, and it's easy to provide non-convex inputs which consequently wouldn't render correctly. So quads as a primitive are less robust, or more complicated, depending on your perspective.
Hacker needed ... for Zarch ;-)
- Rich Talbot-Watkins
- Posts: 2054
- Joined: Thu Jan 13, 2005 5:20 pm
- Location: Palma, Mallorca
- Contact:
Re: Hacker needed ... for Zarch ;-)
When you need only triangles?
There's no difference in the calculation of coordinates for 2xTri or 1xQuad; it's the line-fill length that makes the difference - one long fill is always going to be quicker than two short fills and the difference become more noticeable with optimized line-fill routines such as used here, where it's making use of MEMC quirks to eek out every cycle (quad aligned STM's).
The MUL instruction hadn't even been added to the CPU before he'd finished - the five multiply routines are using loops or lookup tables. I've switched them over to MUL, which is 3x quicker in the case of the lookup table.
The source looks like it was originally coded with a Quad routine in mind, but ran out of time and left it as two Tri calls.
Re: Hacker needed ... for Zarch ;-)
Obviously that makes sense for triangles but it's strange because the 3D book I had went through all the effort of telling me how to split polys into triangles and then how to deal with each type of triangle. But with those polys then - it's easier and faster to do them all at once.sirbod wrote: ↑Tue Aug 22, 2023 1:23 pmWhen you need only triangles?
There's no difference in the calculation of coordinates for 2xTri or 1xQuad; it's the line-fill length that makes the difference - one long fill is always going to be quicker than two short fills and the difference become more noticeable with optimized line-fill routines such as used here, where it's making use of MEMC quirks to eek out every cycle (quad aligned STM's).The MUL instruction hadn't even been added to the CPU before he'd finished - the five multiply routines are using loops or lookup tables. I've switched them over to MUL, which is 3x quicker in the case of the lookup table.
The source looks like it was originally coded with a Quad routine in mind, but ran out of time and left it as two Tri calls.
I suppose maybe for graphics cards/chips that draw all polys in triangle (on PCs and consoles) it would make sense though
That's pretty cool the MUL instruction is faster than look-up tables! Wonder if that would be the same on a 68000. I imagine 68000 is a lot slower in terms of cycles
- NickLuvsRetro
- Posts: 285
- Joined: Sat Jul 17, 2021 4:18 pm
- Contact:
Re: Hacker needed ... for Zarch ;-)
I think a lot of it comes down to context.
In Zarch, the landscape quads are pretty planar. There's not a huge amount of variation in the vertical displacement at each corner. They are also stylistically uniformly colored rather than based on lighting. It makes sense to just load the 4 coordinates and do longer fills. For games that have a lot of jagginess and variation in the terrain grid, without proper topology triangulation it looks very weird.
In Zarch, the landscape quads are pretty planar. There's not a huge amount of variation in the vertical displacement at each corner. They are also stylistically uniformly colored rather than based on lighting. It makes sense to just load the 4 coordinates and do longer fills. For games that have a lot of jagginess and variation in the terrain grid, without proper topology triangulation it looks very weird.
Re: Hacker needed ... for Zarch ;-)
Yes that makes sense as an artistic choice. Those quads do work for Zarch though!NickLuvsRetro wrote: ↑Thu Aug 24, 2023 11:11 am I think a lot of it comes down to context.
In Zarch, the landscape quads are pretty planar. There's not a huge amount of variation in the vertical displacement at each corner. They are also stylistically uniformly colored rather than based on lighting. It makes sense to just load the 4 coordinates and do longer fills. For games that have a lot of jagginess and variation in the terrain grid, without proper topology triangulation it looks very weird.
I always thought it would be great to make the game have this kind of view orientation (like the promotional artwork). Not only does it look super-cool but you get a really clear view of what's going on. When I made videos for Zarch gameplay I made sure to purposefully stay low to make the game look good. When you see a most people play it - they spend 60% of their time in space and you don't even see the landscape much!
Something i just remembered from playing Virus on the Amiga - is they had fish in there. It's been a while since I played that but I think they would jump out of the water and onto the beaches sometimes. I'm sure they were really just using up the Amiga's hardware sprites but I thought that was a cool feature. Otherwise Virus isn't as good (the control is dumbed down and less satisyfing)