Have you thought about using stb_image?

spiroyster wrote:

Have updated, included now is a compiled executable which should work. I'm hoping anyway. (win9x)+ https://github.com/spiroyste […]
Show full quote

PhilsComputerLab wrote:

Windows 9x would be perfect! Voodoo and Voodoo 2 work great with that version. I'm in no rush, and thank you for helping!

Have updated, included now is a compiled executable which should work. I'm hoping anyway. (win9x)+
https://github.com/spiroyster/ppmgl/raw/master/ppmgl.exe

Also ppm versions of your calibration images can be found ...
https://github.com/spiroyster/ppmgl

Thank you!

This is what I'm getting. Is there any runtime library I need to install?

What does 3D calibration do?

DOSfan1994 wrote:

What does 3D calibration do?

It's just a folder I created. Explanation about this thread can be found in the first post. It has to do with video capturing, so this might not be relevant to you at all.

The "Requires a newer version of Windows" sounds like the executable was compiled with a runtime library that cannot work on Windows 9x.
It should probably be recompiled with an older version of the compiler/runtime. Or perhaps KernelEx could fix it.
I see it's built with VS2015? That's never going to work of course. I believe the latest you can use for Windows 9x support is Visual Studio 6.0.

Alas, I fear the worse. Giving the tools at my disposal atm there is no way for me to compile a win9x compatible. 🙁 All I can do is try different switches or maybe MingW. But if Scali says its futile to get something from VS2015 to work with Win9x, I'm inclined to believe him.

I think its safer to avoid patching tools to get it to work since the source is available (if thats what KernelEx does??). I'm not even sure yet if the code will compile with VS6, it should do since it adhears to the standards of the time (I think?). Just need to find a compatible compiler (which I can get my hands at some point).

Interestingly enough though, it looks like VS2005 can compile Win98 compatible binaries (+ redist), does this extend to Win95? Would VS2003 Redist work on Win95?
I can honestly say I have never been tasked or asked to write anything for Win9x specifically (used SoftWindows95 once o.0). So this is my first 😀

I'm also beginning to think the GL driver of the voodoo may not have the clout to degrade the texture (GL standard states 24/32-bit RGB supported, but I don't know if the GL implementation for Voodoo does). Iirc, other implementations would downgrade your textures for <24bit Trucolour displays) displaying representations in lower BPP out of the box. But this depends on how good the GL drivers for voodoo are, and how much they adhere to standard.

Voodoo3 would hopefully work (when I can get you a compatible exe, soon), but Voodoo2 maybe not without some code modification. I'm happy to do this sporadically over time Phil, its a fun little exercise. Also looking at some Glide tutorials so can hopefully get Glide to display the texture (SGL maybe the eventual end goal 😀, if there are any resources for SGL around still?). Direct3D, there are probably others out there better than me since GL is my bread and butter.

leileilol wrote:

Have you thought about using stb_image?

No I have not, thankyou, I'm really liking the look of some of that stuff. Could this mean no more libjgp, no more libpng? I will investigate. 😀

spiroyster wrote:

I think its safer to avoid patching tools to get it to work since the source is available (if thats what KernelEx does??). I'm not even sure yet if the code will compile with VS6, it should do since it adhears to the standards of the time (I think?). Just need to find a compatible compiler (which I can get my hands at some point).

You'll probably run into the classic "Why does this not work?":

1for (int i = 0; i < j; i++)
2{
3    ...
4}
5
6for (int i = 0; i < k; i++) <-- error on this line
7{
8    ...
9}

The issue here is that VC++ 6.0 comes from a different compiler family than the later VC++.NET ones.
VC++ 6.0 and earlier were a fork of the Lattice C++ compiler.
And this compiler had the 'quirk' that it would place the variables declared in the for() statement in the scope above it, rather than in the scope of the for-statement itself.
As a result, int i was already defined when it hits the second for-statement.
An easy fix is to move the declaration outside the for-loop yourself, so it works on both types of compiler:

1int i;
2
3for (i = 0; i < j; i++)
4    ...
5
6for (i = 0; i < k; i++)
7    ...

Basically what you'd do in C anyway.

spiroyster wrote:

Interestingly enough though, it looks like VS2005 can compile Win98 compatible binaries (+ redist), does this extend to Win95?

I seem to recall it did not, but there was a way to patch it.
I know they 'accidentally' included some kernel functions in the runtime that weren't present on Win95 in some of these runtimes.

spiroyster wrote:

Would VS2003 Redist work on Win95?

I wouldn't count on it 😀

Scali wrote:

You'll probably run into the classic "Why does this not work?": […]
Show full quote

spiroyster wrote:

I think its safer to avoid patching tools to get it to work since the source is available (if thats what KernelEx does??). I'm not even sure yet if the code will compile with VS6, it should do since it adhears to the standards of the time (I think?). Just need to find a compatible compiler (which I can get my hands at some point).

You'll probably run into the classic "Why does this not work?":

Copy code to clipboard

1for (int i = 0; i < j; i++)
2{
3    ...
4}
5
6for (int i = 0; i < k; i++) <-- error on this line
7{
8    ...
9}

The issue here is that VC++ 6.0 comes from a different compiler family than the later VC++.NET ones.
VC++ 6.0 and earlier were a fork of the Lattice C++ compiler.
And this compiler had the 'quirk' that it would place the variables declared in the for() statement in the scope above it, rather than in the scope of the for-statement itself.
As a result, int i was already defined when it hits the second for-statement.
An easy fix is to move the declaration outside the for-loop yourself, so it works on both types of compiler:

Copy code to clipboard

1int i;
2
3for (i = 0; i < j; i++)
4    ...
5
6for (i = 0; i < k; i++)
7    ...

Basically what you'd do in C anyway.

spiroyster wrote:

Interestingly enough though, it looks like VS2005 can compile Win98 compatible binaries (+ redist), does this extend to Win95?

I seem to recall it did not, but there was a way to patch it.
I know they 'accidentally' included some kernel functions in the runtime that weren't present on Win95 in some of these runtimes.

spiroyster wrote:

Would VS2003 Redist work on Win95?

I wouldn't count on it 😀

Ha 🤣! This issue has bitten me on the arse more than once. I learned not to use the same loop var naming for sequential for loops within the same block/scope the hard way! Nice to hear a bit of history behind it.

Yes the deeper I ventured (basically cross-referencing the availability of the functions given the standard), I found I was slipping more and more into C ... o.0, even used malloc at one point. Feck it might just re-write in C, I wanted employ exceptions, but then got scared and left them out anyway, so C++ offers no advantages.

I tend to write most of my retro code in straight C. C++ may have existed in the mid-to-late 90s, but the compilers were extremely quirky.
You'll often find that they don't even support things such as namespaces or templates. Good luck trying to compile 'modern' C++ on those 😀
Another advantage is that C compilers generally compile faster and require less memory to compile, because they don't need to do all the fancy preprocessing, name mangling and whatnot.
Besides, C is just a scripting language for that bit of stuff you're not doing in asm, amirite.

Bugger. I really appreciate your effort. Could be one for the "too hard" basket. I was hoping it was something straight forward, but looks like it's not.

It does not have to run under Windows 95! Windows 98 would be perfectly fine.

Scali wrote:

I tend to write most of my retro code in straight C. C++ may have existed in the mid-to-late 90s, but the compilers were extreme […]
Show full quote

I tend to write most of my retro code in straight C. C++ may have existed in the mid-to-late 90s, but the compilers were extremely quirky.
You'll often find that they don't even support things such as namespaces or templates. Good luck trying to compile 'modern' C++ on those 😀
Another advantage is that C compilers generally compile faster and require less memory to compile, because they don't need to do all the fancy preprocessing, name mangling and whatnot.
Besides, C is just a scripting language for that bit of stuff you're not doing in asm, amirite.

1int main(int argc, char** argv)
2{
3 __asm
4{
5	// implementation
6}
7
8return 0;
9}

Yep, C it is then... all C-like languages are just that... C-like, accept no imitation 😀

PhilsComputerLab wrote:

Bugger. I really appreciate your effort. Could be one for the "too hard" basket. I was hoping it was something straight forward, but looks like it's not.

It does not have to run under Windows 95! Windows 98 would be perfectly fine.

Not soo much a hard exercise, just impractical given what's currently at my disposal. Collegues at work use VS6 (they still write some stuff in VB6 😵), so I can get my hands on a compiler. As long as time isn't too much of an issue, I'm more than happy. SGL, Glide stuff has been on my radar for a while, and a simple texture to screen is a nice little task which I can certainly wrap my head around fairly quickly. I've been catching up with Vulkan over Christmas.. and jeez, I'm hoping Glide/SGL ain't gonna get more low level than that? or does it????

If you can do something with Glide, that would be even better 😀

Could even be made to run in DOS 😊

PhilsComputerLab wrote:

If you can do something with Glide, that would be even better 😀

Could even be made to run in DOS 😊

Yep, they may be slightly more difficult, but a GL/Glide program that runs in dos, I would be pretty chuffed with. Will aim for that, after SGL and Glide on Win9x. 😀

If you have an MSDN subscription, I believe you can still download VS6.
Not too long ago I even downloaded VC++ 1.52 from there 😀

Scali wrote:

If you have an MSDN subscription, I believe you can still download VS6.
Not too long ago I even downloaded VC++ 1.52 from there 😀

Excellent thankyou, do you know if the legacy product key is the same for all?. Says its been claimed, but we usually get multiple keys to use?

Nevermind, getting VC++1.52 😀 Now I'm in new territory...

spiroyster wrote:

Scali wrote:

If you have an MSDN subscription, I believe you can still download VS6.
Not too long ago I even downloaded VC++ 1.52 from there 😀

Excellent thankyou, do you know if the legacy product key is the same for all?. Says its been claimed, but we usually get multiple keys to use?

If the key is claimed, you should just be able to see the key in MSDN.
But iirc if you download it from there, the key is already entered in the install script.

Yes I can see the key, I just didn't want to risk jeopardizing others in the team (since they use VS6 for some form of professional endeavour 😵), unless its just one key we can all use. VC++ 2/1.52 don't require them so will stick with them methinks.

Cheers Scali, much appreciated.

You'd really really need to sort out your Win9x binary issue first before you expect to take on SGL later on as that only has hardware drivers for Win9X.

I'd suggest just dumping all those 2K visual studios and head straight to MSVC6. It can work on newer Windows, except for the debugging part hanging once in a while.

Have updated with VS6 compiled binary ppmgl.exe. Give it a whirl let me know.

So which sdk should be used for Voodoo2 and other 3dfx? o.0