There are lots of EGA games... Any of the LucasArts or Sierra adventures.

Also the color errors are due to me not checking the texture format. My code is for ARGB8888 textures, and your PC might use a different one. I have to query the texture format to adjust the RGB masks.

Predator99 wrote on 2020-07-17, 17:42:

OK....where do I have to put it in..? 😉

Agree...stupid question. Works, thanks!!

30 seconds Xenon 2 capture. 1790 Frames detected.

Takes 62 seconds for playback on my i7-4790@3.60GHz.

Version from yesterday was faster. With this one I was able to view at realtime using 16MHz capture. This doesnt work anymore.

37s on a 2013 iMac with i5. So pretty old. I think your slowdown is due to the wrong texture format. If I create a texture in the wrong format it has to be converted before it is uploaded to the GPU. I will fix that soon. I have now incorporated EGA palette lookup, which should accelerate the pixel setting a bit, now I will add Benedikt's render function.

EDIT: Video https://youtu.be/SI_CjpmfOY4

Benedikt wrote on 2020-07-17, 14:50:

Of course the compiler optimizes. It does not usually change your algorithm, though. I totally agree that buffering the input wo […]
Show full quote

Of course the compiler optimizes. It does not usually change your algorithm, though. I totally agree that buffering the input would make sense, ideally in a ring buffer big enough that it definitely contains one full line.
As far as the scaling is concerned, this might then already be the full algorithm for one line, including pixel output:

Copy code to clipboard

1for (target = fb + y * stride, erracc = phase; target < fb + y * stride + width; *target++ = egapal[*source++ & 0x3f], erracc += sclk)
2  while ((erracc -= pclk) >= 0) ++source;

Needless to say, source would have to be initialized to point to the beginning of a line.
sclk would be 24000000, pclk e.g. 14318180 or 7159090 and fb the frame buffer start.
If pclk is 7159090, phase could be a constant, as well.

Ok, while implementing this some questions arose: what is stride in your code? is stride the width of the whole buffer, and width is the actual image width (i.e. 320)?

Also we need to fold in the hsync detection as well. Your code assumes that we never drift over time and it doesn't try to detect either hsync nor vsync.

1 minute GODS

This one is interesting. Crashes after 4 frames, also with my QB64 code...

Works fine for me. Not much action though. Just menu and scores. 😀

root42 wrote on 2020-07-17, 20:11:

Benedikt wrote on 2020-07-17, 14:50:

Of course the compiler optimizes. It does not usually change your algorithm, though. I totally agree that buffering the input wo […]
Show full quote

Of course the compiler optimizes. It does not usually change your algorithm, though. I totally agree that buffering the input would make sense, ideally in a ring buffer big enough that it definitely contains one full line.
As far as the scaling is concerned, this might then already be the full algorithm for one line, including pixel output:

Copy code to clipboard

1for (target = fb + y * stride, erracc = phase; target < fb + y * stride + width; *target++ = egapal[*source++ & 0x3f], erracc += sclk)
2  while ((erracc -= pclk) >= 0) ++source;

Needless to say, source would have to be initialized to point to the beginning of a line.
sclk would be 24000000, pclk e.g. 14318180 or 7159090 and fb the frame buffer start.
If pclk is 7159090, phase could be a constant, as well.

Ok, while implementing this some questions arose: what is stride in your code? is stride the width of the whole buffer, and width is the actual image width (i.e. 320)?

Also we need to fold in the hsync detection as well. Your code assumes that we never drift over time and it doesn't try to detect either hsync nor vsync.

Yes, stride is the width of the buffer, which may or may not be the same as the width of the visible picture.
The code snippet covers the visible part of a single line, only.
Hsync detection would have to precede my code snippet, i.e. you would have to advance the source pointer past the sync pulse.
A later and more sophisticated version should obviously use a more accurate synchronization mechanism that also determines the phase offset.

root42 wrote on 2020-07-17, 20:27:

Works fine for me. Not much action though. Just menu and scores. 😀

Thats very strange...with GODS everything crashes. Switching back to other games all OK.

And for you it works? Even more strange....

Smells like a stray pointer issue, if you ask me. Possibly triggered by an unexpected input signal.

Should be more GODS action in here. Still crashes after 13 Frames.

What did you change in the code? 😉

So the overdraw is removed, and I tried to incorporate the phase adjustment. I tried different positions for it, I also adjusted pclk to use the same factor as Predator99's formula (319/1070). But the jitter is there, so my sampling grid due to the error accumulation is not fitting the samples perfectly. I am too tired now. Someone else please have a look at the repo.

You can adjust phase with cursor left and right (adjustments are minimal).

I did not incorporate Benedikt's algorithm verbatim right now, because it was harder to debug in its compactness. We can refactor later, but I think the current code isn't that much more ineffective, but more readable and better for debugging...

Benedikt wrote on 2020-07-17, 20:50:

Smells like a stray pointer issue, if you ask me. Possibly triggered by an unexpected input signal.

Think I have it: At some point no more data is delivered via STDIN. I printed all values for "value" during processing. The last one displayed is "-1"?! Then nothing more is coming in.
Seems to be an EOF which is handled different between Linux and Windows?

But why does this problem only appear with GODS so far?

Still strange...

Got it. Almost. I was forgetting to reset the error accumulator after each scanline. Fixed that. Now to figure out the right phase...?

Did a quick test but I dont see a big effect when using the cursor keys...will also quit for today.

Predator99 wrote on 2020-07-17, 22:10:

Think I have it: At some point no more data is delivered via STDIN. I printed all values for "value" during processing. The last […]
Show full quote

Benedikt wrote on 2020-07-17, 20:50:

Smells like a stray pointer issue, if you ask me. Possibly triggered by an unexpected input signal.

Think I have it: At some point no more data is delivered via STDIN. I printed all values for "value" during processing. The last one displayed is "-1"?! Then nothing more is coming in.
Seems to be an EOF which is handled different between Linux and Windows?

But why does this problem only appear with GODS so far?

Still strange...

Have it:
https://stackoverflow.com/questions/12942518/ … -0x1a-character
So under Windows I have to include...:

#include <io.h>
#include <fcntl.h>
...
int main()
{
_setmode (_fileno( stdin ), _O_BINARY );

GODS is running now!

root42 wrote on 2020-07-17, 22:08:

So the overdraw is removed, and I tried to incorporate the phase adjustment. I tried different positions for it, I also adjusted pclk to use the same factor as Predator99's formula (319/1070). But the jitter is there, so my sampling grid due to the error accumulation is not fitting the samples perfectly. I am too tired now. Someone else please have a look at the repo.

You can adjust phase with cursor left and right (adjustments are minimal).

I did not incorporate Benedikt's algorithm verbatim right now, because it was harder to debug in its compactness. We can refactor later, but I think the current code isn't that much more ineffective, but more readable and better for debugging...

I believe that the initial "phase" value should always be positive with this exact algorithm.
The adjustments using the cursor keys are indeed minimal, probably too minimal. You'd have to press a key several thousand times to see a noticeable difference.

Benedikt wrote on 2020-07-18, 10:39:

I believe that the initial "phase" value should always be positive with this exact algorithm.
The adjustments using the cursor keys are indeed minimal, probably too minimal. You'd have to press a key several thousand times to see a noticeable difference.

Oh, I tried with phase*pclk or phase += 1000 but it didn't really help. I am open to suggestions and experiments.

One setting that would be nice would be to apply the scaling done in this if the user wants to : https://www.youtube.com/watch?v=YvckyWxHAIw
(stretch the image to 640x1200 using nearest neighbor algorithm and then shrink it to 640x480 using bilinear filtering)
This will let us have the perfect aspect ratio adapted to modern monitors without loosing too much on sharpness.

root42 wrote on 2020-07-18, 11:57:

Benedikt wrote on 2020-07-18, 10:39:

I believe that the initial "phase" value should always be positive with this exact algorithm.
The adjustments using the cursor keys are indeed minimal, probably too minimal. You'd have to press a key several thousand times to see a noticeable difference.

Oh, I tried with phase*pclk or phase += 1000 but it didn't really help. I am open to suggestions and experiments.

In any case, the initial value should be between 0 and sclk, if I'm not mistaken.
Something in the ballpark of 1000000 should be a good step size for initial testing.