Problem with 8bit graphics under Windows... perhaps?

[xlucas]

Hi, folks. I'm having a strange problem. I made this old game back in 2000 and last year, I made an adaptation, editing the QB code to run in FreeBasic and making it so that it would run under Linux and Windows. I scaled the graphics from 320x200 to 960x600 (3x each dimension), but kept the 8bit graphics with palette. During the months I've been working on the adaptation, I compiled the source many, many times for both platforms and it was all going well. Now I've made some tiny changes to some of the texts inside to make the project free software and when I compile it and run it, something's not right and I can't figure out what:

In GNU/Linux, it's still perfectly functional. I do not have Windows, but I've been using Wine to compile and run the Windows port. I still have an executable I built a few months ago which has minimal differences and I can run it in my current system with Wine, no problem. But this one, when I run it, creates the window, but seems to be unable to write to the window. It responds to the keys and you can hear that it's working, but the window gets no graphics on it.

The game allows to be put in full screen mode, by changing the config file video=normal to video=fullscreen. If I do that, the graphics can be seen, but all stretched and of course, no window. Another mode, video=special, creates a windows without border that takes up the whole of the desktop. This one doesn't work either with Wine. I check the code and I don't see what can be wrong. I haven't modified anything having to do with the graphics, and I don't have a true Windows system to test it under.

You can get the game, called Syderal, from here: http://dimioca.com/syderal. The two Linux executables and the Windows executable are there and there's also the source code in the source directory if you want to compile it yourselves. It's too long to post here. Look at the Sub GenInit, which is the one that initialises the graphics.

Any hint of what could be happening? Thank you, guys :)

[St_W]

It works perfectly fine on my Windows 7 PC - bothe the pre-compiled EXE and the EXE I compiled myself from the sources. Maybe an issue with Wine? Did you update Wine recently? Btw. I'd suggest to set up a Windows VM. You can download 32-bit versions freely from https://developer.microsoft.com/en-us/m ... tools/vms/

[xlucas]

Oh, how strange! I have not updated Wine, but I've updated my whole OS about 20 days ago and installed Wine shortly after, so it should be new. Also, it's strange how other executables compiled earlier run normally. I'll experiment compiling different things to see what happens.

Thank you very much for testing it! I know that a virtual machine gives a more accurate environment for testing, but I would prefer to avoid using Microsoft products when possible. Anyway, it calls my attention that you say 32bit systems are given free. Did Microsoft release its old OSs as freeware? I hope I can solve it with Wine. It comes in very handy, since the only thing I run in a Windows environment is FBC and the programs I compile with it, to test them. I'd probably need a more powerful computer to run a whole true OS in a box. I don't know. I haven't tried, really.

If anybody's getting a different result from running the program, please let me know. Thank you :)

EDIT: I found what causes the problem and now I know how to avoid it, but I don't see why this causes a problem. Apparently, if you compile with FBC for Windows a program that first sets up a graphics mode and then switches to another (windowed) mode, for some reason, the drawing primitives will not work on Wine. I'll modify the code so that it just stays in one fixed graphics mode, but it'd be interesting to study why this occurs. Thanks!