Thomas Harte
|
083b678785
|
Quickie: observed that the initial position is one scanline dirty, not zero. Also switched to a size_t on the write pointer, size_t being the correct C size for into-memory offsets.
|
2015-08-17 00:25:32 -04:00 |
|
Thomas Harte
|
a693c081f8
|
Switched on the appropriate compiler warnings re: signed comparisons and implicit conversions. Fixed all less-than-explicit calls.
|
2015-08-16 16:08:29 -04:00 |
|
Thomas Harte
|
67e82c713f
|
Broke assumption that every item in a vertex description is a short, specifically turning lateral into a byte. Which buys me a byte for phase, if that's sufficient.
|
2015-08-05 21:12:33 -04:00 |
|
Thomas Harte
|
04c2640b15
|
Made a quick attempt to allow vsync triggers only on the raising edge of a sync signal. Will need to investigate more thoroughly.
|
2015-08-03 08:42:05 -04:00 |
|
Thomas Harte
|
55017b78a5
|
Made an attempt to unify my variable storage (and, technically, to get beam size correct across the frame).
|
2015-08-02 19:30:45 -04:00 |
|
Thomas Harte
|
be421587ad
|
Eliminated the vertical retrace counter; vertical retrace ends when the beam gets back to the top.
|
2015-08-02 13:48:35 -04:00 |
|
Thomas Harte
|
c1a12ad4df
|
Fix to make sure end of vertical sync is always correctly spotted as an event, rather than just happening off the books. So I can now watch Joust roll to its heart's content.
|
2015-07-31 18:15:59 -04:00 |
|
Thomas Harte
|
9c91f1a2eb
|
Added an attempt at NTSC/PAL autodetection, based on number of missed vertical syncs.
|
2015-07-31 18:04:33 -04:00 |
|
Thomas Harte
|
a5d66e9dd6
|
Factored out a few more constants, started trying to ensure there's enough slack and the mechanisms in place for the CathodeRayView to hold onto two frames if it desires, for potential phosphor simulation, switched once again to additive blending — much more like a real CRT — and added a sine function across the width of spans per my understanding of how an electron gun actually fires.
Why do all this when overall timing is still so far off? It helps me more easily see how overall timing is so far off.
|
2015-07-31 17:47:10 -04:00 |
|
Thomas Harte
|
65bb31d55b
|
With around about a thousand issues, not the least of which being sometimes unsafe memory accesses, I've at last got pixels on screen.
|
2015-07-26 23:50:43 -04:00 |
|
Thomas Harte
|
cea2580000
|
Upped internal precision a little.
|
2015-07-24 23:36:44 -04:00 |
|
Thomas Harte
|
ecb2898bd5
|
The overall architecture of who has responsibility for what is now very askew but: the CRT now outputs a tightly packed short buffer, with the probable OpenGL destination in mind. So it's now all fixed arithmetic internally. CRTFrame is reduced to a plain C struct with the intention that the OpenGL view will take responsibility for it and stop doing the back-and-forth sprint on getting buffer data. The Atari 2600 now outputs explicit blanks rather than level blacks for its border, so that it's easier visually to debug the CRT in its form as far as it has currently progressed: to drawing lines where the cathode ray gun would run while outputting pixel. I note that I'm still not quite getting vertical sync right yet — I'm just accepting it anywhere in teh frame — but that should be an easy fix.
|
2015-07-24 23:29:45 -04:00 |
|
Thomas Harte
|
33c06baffa
|
Explicitly separated vertical and horizontal sync event tracking, so as explicitly to be able to handle a coincidental simultaneous occurrence of both. Also for clarity.
|
2015-07-23 18:53:18 -04:00 |
|
Thomas Harte
|
065050115f
|
Made an attempt to switch to a triple-buffering scheme for CRT outputs, with an eye towards asynchronicity.
|
2015-07-22 20:33:20 -04:00 |
|
Thomas Harte
|
963cb2f6fb
|
Attempted to switch to slightly more meaningful names within the CRT and implemented a delegate to investigate output. Working on it.
|
2015-07-22 18:15:18 -04:00 |
|
Thomas Harte
|
908c171d2d
|
Commented the heck out of this thing, to put my thoughts in order if nothing else.
|
2015-07-21 16:37:39 -04:00 |
|
Thomas Harte
|
a1a1b15d18
|
Made a quick attempt to accumulate a list of detected output runs. Which means finally having to specify normal frame height. I'm already at too many magic formulae though, so this will need proper revision when I'm next awake. Definitely my horizontal position advancement is way off.
|
2015-07-20 23:18:56 -04:00 |
|
Thomas Harte
|
4fa315ab4d
|
This looks a lot closer to correct. The loss of horizontal sync during vertical sync is odd but the two should be fully decoupled in here. I'll have to check. Probably I've got something wrong. There are approximate sinusoidals when re-establishing sync, so that's promising as to the flywheel.
|
2015-07-20 21:58:32 -04:00 |
|
Thomas Harte
|
4695295dd1
|
Made complete attempt at sync discrimination. But I seem somehow to be locking such that horizontal sync is in the middle of the line. Obviously my flywheel is at fault somehow.
|
2015-07-20 21:43:00 -04:00 |
|
Thomas Harte
|
4e4c082a05
|
Made some minor attempt at proper sync response. I think I've gone way off piste and overcomplicated it.
|
2015-07-19 23:43:22 -04:00 |
|
Thomas Harte
|
4a1e9fe2a8
|
Rephrased the CRT as owning an arbitrary number of buffers and vending storage space for pixel output. That much better maps to potential implementations of this thing in GLSL, with ES 2.0's limitations kept in mind.
|
2015-07-19 21:21:34 -04:00 |
|
Thomas Harte
|
7df5025eef
|
Started sketching out the delegate interface that will allow a branch from the CRT into whatever native display system is used by a particular platform.
|
2015-07-19 18:32:42 -04:00 |
|
Thomas Harte
|
2d0f861474
|
Incoming: a 'CRT' class, to receive information intended for a cathode ray tube. To decode sync, etc.
|
2015-07-19 13:36:27 -04:00 |
|