6502/CLK
1
0
Fork 0
mirror of https://github.com/TomHarte/CLK.git synced 2024-12-27 01:31:42 +00:00
Code Issues Projects Releases Wiki Activity
e93dbdb463
CLK/Outputs/CRTFrame.h

52 lines
938 B
C
Raw Normal View History

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-25 03:29:45 +00:00
//
// CRTFrame.h
// Clock Signal
//
// Created by Thomas Harte on 24/07/2015.
// Copyright © 2015 Thomas Harte. All rights reserved.
//
#ifndef CRTFrame_h
#define CRTFrame_h
#ifdef __cplusplus
extern "C" {
#endif
Reshuffled to make the OpenGL view explicitly a conduit for CRT-style output, and to give it responsibility for frame drawing. Which is still an awkward thread hop for the time being, but I've yet to read up on the advocated approach to multithreading with an NSOpenGLView; it looked like special provisions were available.
2015-07-26 19:13:46 +00:00
typedef struct {
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-25 03:29:45 +00:00
uint8_t *data;
Switched on the appropriate compiler warnings re: signed comparisons and implicit conversions. Fixed all less-than-explicit calls.
2015-08-16 20:08:29 +00:00
unsigned int depth;
Reshuffled to make the OpenGL view explicitly a conduit for CRT-style output, and to give it responsibility for frame drawing. Which is still an awkward thread hop for the time being, but I've yet to read up on the advocated approach to multithreading with an NSOpenGLView; it looked like special provisions were available.
2015-07-26 19:13:46 +00:00
} CRTBuffer;
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-25 03:29:45 +00:00
typedef struct {
Switched on the appropriate compiler warnings re: signed comparisons and implicit conversions. Fixed all less-than-explicit calls.
2015-08-16 20:08:29 +00:00
uint16_t width, height;
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-25 03:29:45 +00:00
} CRTSize;
Reshuffled to make the OpenGL view explicitly a conduit for CRT-style output, and to give it responsibility for frame drawing. Which is still an awkward thread hop for the time being, but I've yet to read up on the advocated approach to multithreading with an NSOpenGLView; it looked like special provisions were available.
2015-07-26 19:13:46 +00:00
typedef struct {
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-25 03:29:45 +00:00
CRTSize size, dirty_size;
Switched on the appropriate compiler warnings re: signed comparisons and implicit conversions. Fixed all less-than-explicit calls.
2015-08-16 20:08:29 +00:00
unsigned int number_of_buffers;
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-25 03:29:45 +00:00
CRTBuffer *buffers;
Switched on the appropriate compiler warnings re: signed comparisons and implicit conversions. Fixed all less-than-explicit calls.
2015-08-16 20:08:29 +00:00
unsigned int number_of_runs;
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-06 01:12:33 +00:00
uint8_t *runs;
Reshuffled to make the OpenGL view explicitly a conduit for CRT-style output, and to give it responsibility for frame drawing. Which is still an awkward thread hop for the time being, but I've yet to read up on the advocated approach to multithreading with an NSOpenGLView; it looked like special provisions were available.
2015-07-26 19:13:46 +00:00
} CRTFrame;
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-25 03:29:45 +00:00
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-06 01:12:33 +00:00
typedef uint16_t kCRTPositionType;
typedef uint16_t kCRTTexCoordType;
typedef uint8_t kCRTLateralType;
typedef uint8_t kCRTPhaseType;
static const size_t kCRTVertexOffsetOfPosition = 0;
static const size_t kCRTVertexOffsetOfTexCoord = 4;
static const size_t kCRTVertexOffsetOfLateral = 8;
static const size_t kCRTVertexOffsetOfPhase = 9;
static const int kCRTSizeOfVertex = 10;
Started making the format of data included in a CRTFrame less a matter of variously hard-coded magic constants. Which will allow me to separate the idea of an internal lateral position from the direct texture coordinate, avoiding precision sampling errors at the top and bottom.
2015-08-02 18:25:21 +00:00
Not that it makes a lot of difference, there being no names to mangle, but moved the closing `#ifdef __cplusplus` to the idiomatic place.
2015-08-19 00:33:59 +00:00
#ifdef __cplusplus
}
#endif
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-25 03:29:45 +00:00
#endif /* CRTFrame_h */
Reference in New Issue Copy Permalink