Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Documentation about the Vampire hardware

1080p With Vampirepage  1 2 3 4 5 6 7 8 

Vladimir Repcak

Posts 359
07 Jun 2020 22:35


Well. maybe not so fast with the coding.

  Just got a Tornado Watch Alert, so I better go do some disaster prepping, charging batteries, hauling water, cans and stuff.

There was a recent F4 that touched down nearby, so best to be as prepared as possible. The rest is fate anyway :)

Ironically, last night I watched Twister on NFLX :- ))))))))))))



Vladimir Repcak

Posts 359
09 Jun 2020 23:05


There were couple Tornado touchdowns but about 150 miles from here, so all good. Well, for 2-3 days anyways, as the Tornado Season is in full bloom...

So, to have some executable for 1080p, I enabled the old high-poly environment but suddenly got a glitch, after I changed the parameters of my 3D perspective recently - which had to happen due to high-poly Player ship (which didn't have enough Z-precision near the camera).

I spent over 1.5 days debugging the random visual glitch and it turns out it happened only on ONE polygon out of 3,000+ triangles. And only under specific camera position.

I implemented a workaround, but then several polys started to get clipped too early.

Fixing that resulted in quite a few per-polygon ops. Which I didn't like, because only one polygon out of over 3,000 was doing that.

So, I ran deeper down the rabbit hole and today found out there was a numerical precision issue with signed division. At some point, my vasm compiler stopped doing divs.w and replaced it with divs.l (16 vs 32 bit signed division).
That resulted in occasional sign flip of the transformed vertex, which then - correctly - got interpreted by the rest of pipeline as NOT outside of screen. Hence rendering a poly with incorrect coordinates (due to divs.l issue)

Funny thing is that by spending half more day on debugging this, despite having a workaround (I never like introducing more cycle cost per vertex), not only did I remove the ~25,000 ops per frame (induced by the sanity check that had to happen per polygon), but I also removed 4 ops per vertex during transform, which in itself totals to around 20,000 ops per frame saved additionally :)

Somehow, I got it working under WinUAE in 1920x1080, so I at least have a confirmation that my engine works in FullHD.

Now, before I send out the executable for testing, there are 2 more things:
1. Aspect Ratio - vertices should end up in same region of screenspace regardless of resolution, which hasn't yet been implemented. Hopefully, this half-day exercise won't reveal another series of issues. But if it does, I can quickly enable polygon-hunting debugging routines from last 2 days, so this is probably best time to do it anyway.

2. Removing CGX FrameBuffer conversion (after rendering is done) for SAGA video pointer change via compile-time flag (so I can keep working under emulator, but final build will work by flipping just one pointer). That has to happen before final release anyway, so might as well do it now.
Thing is, at FullHD, we're talking 2 Mil pixels, so that certainly will take some considerable amount of time for CGX library and only god knows how well it is implemented...


posts 142page  1 2 3 4 5 6 7 8