Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

I took a little time to look into this today. Other than the sound library, all the other non-DROD libraries compile fine. However, DRODLib was giving me tons of warnings and errors using SGI\'s compiler.

It would probably be better to use g++ instead anyways, should make the porting to any other Unix that much easier. Come to find out that we don\'t even have that installed on our SGIs! Aaargh. So I grabbed the source to g++ and started compiling it, and it\'s been going for a good 3-4 hours now, no idea when it will finally finish.

One big thing that caused a lot of problems with SGI\'s CC - In Types.h, there is a type \"WCHAR\" that is typedef\'d to an unsigned short. This seems to be used interchangably with the standard type wchar_t. This causes some problems because with SGI\'s CC, wchar_t is actually an unsigned long. Oof. Is there a good reason WCHAR is around instead of just using wchar_t all the time?



____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Schik wrote:
One big thing that caused a lot of problems with SGI\'s CC - In Types.h, there is a type \"WCHAR\" that is typedef\'d to an unsigned short. This seems to be used interchangably with the standard type wchar_t.

This causes some problems because with SGI\'s CC, wchar_t is actually an unsigned long. Oof. Is there a good reason WCHAR is around instead of just using wchar_t all the time?

I\'m thinking just change the WCHAR typedef to:

typedef wchar_t WCHAR;

...but I will make sure Metakit is good with it. Hold on...

(rebuilding)

Yes, it\'s fine.

We could search and replace on all the WCHAR\'s but I\'d rather just change the typedef to define as wchar_t.

Does that work?

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

It does help, but there seem to be a lot of other win32 specific function calls:

_wtoi()
_itow()
_tzset()
_ltoa()

Having various other errors, but I\'ll keep plugging away...




____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Schik wrote:
It does help, but there seem to be a lot of other win32 specific function calls:

_wtoi()
_itow()
_tzset()
_ltoa()

Wow. I didn\'t know these were win32-specific.

We could write our own versions of these. For _wtoi() and _itow(), we could wrap the functions with code that handle ansi/wide char string conversions. _ltoa() can be written from scratch pretty simply.

_tzset() is harder. I have been surprised in the past to find out what a horrific pain it is to determine the daylight savings time adjustment. It is one thing to know what timezone the user is in and adjusting for that. Getting the right DST takes several pages of well-informed code, because you have to take into account different rules from different places in the world.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

That\'s exactly what I had planned for _wtoi, _itow, and _ltoa. I wasn\'t quite sure what to do about _tzset though.

One other thing I\'m starting to worry about (not that I\'m close to this point yet) is the big-endian/little-endian problem. There\'s going to be a whole lot of byte-swapping to do, but I think it should only be when converting the stuff in the Dat1.11c directory to drod1_5.dat. But that brings up a question, or maybe a lot of them -

- Newly created levels are created directly into the drod1_5.dat file. When exported, they need to be importable no matter what the endianness (?) of the system is. I have some projects that communicate between an SGI/Sun and a PC via TCP, and we generally just use htonl(), ntohl(), htons(), and ntohs() to fix the problem. This should work, but there would be a ton of changes. Basically the .dat file would have to be stored in network format, which is the same as the SGI format, not the PC.

Thoughts?


____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Thanks for working on this, Schik!

Schik wrote:
That\'s exactly what I had planned for _wtoi, _itow, and _ltoa. I wasn\'t quite sure what to do about _tzset though.

Well, I am ignorant about Irix and Unix in general. Is there a system-wide timezone setting stored somewhere? If there is, then we can write a function to get the timezone and return the adjustment. I feel okay about using O/S-specific code if there is not something O/S-independant to use and if it is written with conditional compilation.

If there is not a system-wide timezone setting, we can add a section to DROD.ini that keeps the timezone and prompt for the timezone the first time DROD runs.

As previously mentioned, DST calcs are a dirty job. I\'d be willing to let them go for now, if we just have the timezone adjustments working.

If we calculate our own adjustments, then the CDbDateTime code may need to be updated to add the adjustment if appropriate. I don\'t know if the time functions in Irix use environment variables to adjust time like Windows does.

One other thing I\'m starting to worry about (not that I\'m close to this point yet) is the big-endian/little-endian problem.

Yeah, that would be something to worry about, but I think it won\'t be so bad.

The Metakit database library is used to store and retrieve data in .DAT files. I understand that it automatically performs big-endian/little-endian conversions when data is accessed. So a .DAT file created on a big-e system will be usable on a little-e system.

There are some things that get stored as binary data with Metakit, but I\'m pretty sure that all this data is either Unicode or byte-level concatenations.

- Newly created levels are created directly into the drod1_5.dat file. When exported, they need to be importable no matter what the endianness (?) of the system is.

Mike Rimer\'s export format is XML and all numbers are represented as text strings. So I think we avoided endian problems there too.

Before it\'s all over, we will probably find some places where the endian problem comes up, but for the most part it should be okay. Watch me be drastically wrong about that!

Another way to look at it: once you get DROD running, it is either going to like that .DAT file or do some terrible things in response. Same for exporting/importing. We can come up with test cases that should uncover endian problems pretty quickly.

-Erik


____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

ErikH2000 wrote:
Well, I am ignorant about Irix and Unix in general. Is there a system-wide timezone setting stored somewhere?

According to my man pages:
\"localtime, localtime_r, gmtime, and
gmtime_r return pointers to tm structures,
described below. localtime and localtime_r
correct for the main time zone and possible
alternate (``daylight savings\'\') time
zone;\"

But VS\'s help says:
\"localtime corrects for the local time
zone if the user first sets the global
environment variable TZ. When TZ is set,
three other environment variables (_timezone,
daylight, and _tzname) are automatically set
as well. See _tzset for a description of
these variables. TZ is a Microsoft extension
and not part of the ANSI standard definition
of localtime.\"
So it looks like localtime should return a good structure on a Unix box but the current method should be used for Windows.

The Metakit database library is used to store and retrieve data in .DAT files. I understand that it automatically performs big-endian/little-endian conversions when data is accessed. So a .DAT file created on a big-e system will be usable on a little-e system.

Ahh, quite a relief. I\'ll cross my fingers and hope it all works without changing anything

Mike Rimer\'s export format is XML and all numbers are represented as text strings. So I think we avoided endian problems there too.

Another relief. I was looking at the files in Dat1.11c and got worried. Come to think of it, I was wondering why expat was linked in. Aha!

Edit: the code tags made it ugly

[Edited by Schik on 02-14-2003 at 01:12 PM GMT]

____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

admin
Level: Legendary Smitemaster
Rank Points: 8
IP: Logged

Schik wrote:
So it looks like localtime should return a good structure on a Unix box but the current method should be used for Windows.

Good deal! I\'m glad we don\'t have to write time adjustment code.

-Erik

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

Okay, DRODLib is almost compiling. All that I have left is in CFiles:

- WriteDRODProfileString
- GetDRODProfileString
- In InitClass, GetModuleFileName() is called. The only standard way I know of to get the full path of the called program is argv[0] in main(). Does anyone know of any other way? If not, um... should I modify main() to put the path into a global?

As for the *ProfileString stuff, writing a little class to handle an INI file should be pretty simple unless there\'s an easier way I\'m overlooking.

Everything else matched up pretty well with standard functions.

This is just trying to get it to compile, I haven\'t even tried Unicode stuff yet.



____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

admin
Level: Legendary Smitemaster
Rank Points: 8
IP: Logged

Schik wrote:
Okay, DRODLib is almost compiling.

Nice!

...

The only standard way I know of to get the full path of the called program is argv[0] in main(). Does anyone know of any other way? If not, um... should I modify main() to put the path into a global?

That sounds okay, though I\'d like to avoid the global. CFiles is the only place that needs to use the module filepath, so I\'d like to just keep the variable there. How about changing the CFiles constructor:

CFiles(const char *pszSetAppPath = NULL)
//Constructor.
{
if (this->dwRefCount == 0)
{
ASSERT(pszSetAppPath != NULL);
InitClass(pszSetAppPath);
}
this->dwRefCount++;
}

CFiles::InitClass() would need to take a path param and store it in its pszAppPath member.

Init() in Main.c would need to take a path param from Main() and pass it in the CFiles construction.

Sound alright?

As for the *ProfileString stuff, writing a little class to handle an INI file should be pretty simple unless there\'s an easier way I\'m overlooking.

...

Parse away!

-Erik

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Schik wrote:
One other thing I\'m starting to worry about (not that I\'m close to this point yet) is the big-endian/little-endian problem. There\'s going to be a whole lot of byte-swapping to do, but I think it should only be when converting the stuff in the Dat1.11c directory to drod1_5.dat.

I didn\'t read this carefully enough before. You are right--this is where the endian problems would come up. However, I don\'t think we need to worry about making this code work cross-platform, since we aren\'t going to need to convert dat1.11c in the future, just 1.5 and other Metakit-stored formats. In DRODUtil, a simple but clean way to handle a 1.11c import request might be to put something like this in and exit early.

#ifndef WIN32
//Endian conversion is needed for import
//to work
printf(\"This feature is only supported in Windows.\\r\\n\") ;
return;
#endif

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

Now all of the DRODLib issues are resolved (but largely untested).

On to DROD - CFileDialogWidget took some work but I think it\'s okay now. CBitmapManager also had some Win32 file access - not a problem. Anything fmod related is #ifdef\'d out of CSound && CSoundEffect.

I\'ve got a smallish issue with CFontManager - SDL_ttf uses its own typedef (unsigned short) for Unicode chars, instead of using wchar_t, so it\'s broken on the SGI. Not sure how to resolve that, other than converting the wstring to char* and using the non-unicode TTF_RenderText_Solid.




____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Schik wrote:
I\'ve got a smallish issue with CFontManager - SDL_ttf uses its own typedef (unsigned short) for Unicode chars, instead of using wchar_t, so it\'s broken on the SGI. Not sure how to resolve that, other than converting the wstring to char* and using the non-unicode TTF_RenderText_Solid.

Hmmm. I don\'t know if this is right, but tell me what you think...

SDL_TTF compiles as-is, right? Uint16 (SDL_TTF\'s type for unicode strings) is always going to be 2 bytes and wchar_t is always going to be 2 bytes. In the places where we make calls into SDL_TTF, how about putting at the top of the function:

ASSERT(sizeof(WCHAR)==sizeof(Uint16));

...just to be stupid-safe. And then cast for calls to SDL_TTF, like:

TTF_RenderUNICODE_Shaded(pFont->pTTFFont, (Uint16 *)pwczText, pFont->ForeColor, pFont->BackColor);

Does this sound reasonable? I may have misunderstood the problem.

I don\'t want to convert the unicode strings to single-byte, because we want to be able to display other character sets on the screen if and when DROD is localized to other languages that use them.

Also, it would be a bit of a pain to make modifications to SDL_TTF, because then we have to keep a modified copy of it around, and merge it if an update to SDL_TTF comes up. To be avoided.

-Erik

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

erikh2000 wrote:
SDL_TTF compiles as-is, right? Uint16 (SDL_TTF\'s type for unicode strings) is always going to be 2 bytes and wchar_t is always going to be 2 bytes.

There\'s the problem. wchar_t is unsigned long on my SGI. Not sure why, but it is.

____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Schik wrote:
There\'s the problem. wchar_t is unsigned long on my SGI. Not sure why, but it is.

Oh! Then on the SGI we\'ve got 4-byte wchar_t\'s. Yikes.

Maybe we should change WCHAR back to unsigned short, and if there are any wide string functions we are using, write 2-byte versions of them that take a WCHAR.

There is another problem with wstring. On my computer it\'s defined:

typedef basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t> > wstring;

I\'m guessing we get 4-byte wstrings on the SGI too. I checked in changes to define a WSTRING like so:

typedef basic_string<WCHAR, char_traits<WCHAR>, allocator<WCHAR> >
WSTRING;

...and changed all the wstrings to WSTRINGs. I also took out a few wchar_t references. Update from CVS if you want that. I wonder how close you are to compiling with those changes.

Schik, I realize that this invalidates an earlier piece of advice. I\'ll try not to give flip answers, and please apply your own judgment and tell me when I\'m off.

-Erik


____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

So you want to basically remove all usage of the build in wchar_t, and make our own implementations of any functions that use wchar_t?

A quick search shows that we use:
wcscpy, wcscmp, wcslen, wcscat, wcsncpy.

There are also several places where wchar_t*s are implicitly declared: L\" (1)\" for instance.

I\'ll admit to being pretty Unicode ignorant - how do you convert a char to a 16 bit Unicode character using?

Actually, the functions I can do without any knowledge except the assumption that a NULL is still 0 - the only question I have is the above - how to convert a string literal to a WCHAR* or WSTRING?



____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Schik wrote:
So you want to basically remove all usage of the build in wchar_t, and make our own implementations of any functions that use wchar_t?

Yeah, that\'s the idea. I am right that wchar_t uses 4 bytes in your build? If we used 4-byte wchar_t\'s then we would need to perform run-time conversions on all the strings in the database.

...

There are also several places where wchar_t*s are implicitly declared: L\" (1)\" for instance.

Groan. This is harder. I\'m doing some work on it now that I\'ll check in after a bit.

I\'ll admit to being pretty Unicode ignorant - how do you convert a char to a 16 bit Unicode character using?

Either the first or second byte is 0 and the other one is just like an ASCII char.

-Erik


____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

zex20913
Level: Smitemaster

Rank Points: 1721
Registered: 02-04-2003
IP: Logged

Wow. I am so beyond lost. Never shall I ever take a Comp. Sci. class.

____________________________

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Heya, Schik. I checked in a bunch of changes. The L\" string literals are no longer present.

Note that some huge sections of text have been commented out for the end-of-game sequence. This text is going into the database, so I didn\'t worry about fixing all the L\'s.

I made an L() macro that can be used sparingly in place of L\". See new wchar.h file for details.

The wchar module may be a good place to put replacement functions for wcslen, wcscat, etc.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

zex20913 wrote:
Wow. I am so beyond lost. Never shall I ever take a Comp. Sci. class.

Yeah, and remember: big-endian to little-endian type conversion is a surefire conversation-killer at parties.

-Erik


____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

erikh2000 wrote:
I made an L() macro that can be used sparingly in place of L\". See new wchar.h file for details.

Unless I\'m missing something, AsciiToUnicode() copies the ascii string to an internal static buffer, then returns a pointer to that buffer (actually, a pointer to the NULL at the end of the string (Oops )).

If someone writes WCHAR* str = L(\"DROD\" );, as could would be okay before, str will point to the buffer, which will change the next time L() is called.

Conversely, if L() were changed to malloc memory for the new string, then writing:
WSTRING str;
str += L(\"DROD\" );
would be a memory leak.

Also, the way it is now, if the following code (in CDbRoom) is converted to use the new macro:
const WCHAR numberText[19][10] = {
L\"Once\",L\"Twice\",L\"Thrice\",L\"Four\",L\"Five\",
L\"Six\",L\"Seven\",L\"Eight\",L\"Nine\",L\"Ten\",
L\"Eleven\",L\"Twelve\",L\"Thirteen\",L\"Fourteen\",L\"Fifteen\",
L\"Sixteen\",L\"Seventeen\",L\"Eighteen\",L\"Nineteen\"
};

All the strings will end up being \"Nineteen\".
We can obviously fix these things easily, but if L() stays as-is now, everyone will have to be careful in the future when using it.



____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Schik wrote:
Unless I\'m missing something, AsciiToUnicode() copies the ascii string to an internal static buffer, then returns a pointer to that buffer (actually, a pointer to the NULL at the end of the string (Oops )).

Yes, I meant to return a pointer to the *beginning* of the buffer. Sorry. Also I wanted to use a static buffer so that it wouldn\'t be necessary to alloc a buffer in the function or caller of the function. I understand what you are saying about how care must be taken to make sure you don\'t overwrite the buffer before using it.

Also, the way it is now, if the following code (in CDbRoom) is converted to use the new macro:
const WCHAR numberText[19][10] = {

Ah, I missed that place. The L macro was really just meant for a few places where there is long text that doesn\'t come from the database. Most places I am setting up constant buffers to hold strings.

All the strings will end up being \"Nineteen\". We can obviously fix these things easily, but if L() stays as-is now, everyone will have to be careful in the future when using it.

Okay, I changed my mind. No reason to put something dangerous into the code just to avoid writing an extra line to manage a string buffer.

I took out the L() macro and revised AsciiToUnicode(). It\'s checked in.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

Looks good, that\'s the best solution I could think of as well - unfortunately it requires more code changes, but... oh well. I agree that it\'s much better than having to allocate memory all over the place.

Thanks for the help.


____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

pireas [ /usr/scratch/schikore/priv/Caravel/DROD 74 ] ./drod
Segmentation fault (core dumped)


let the fun begin.


____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

Well, I got to the point where the spinning heads come up. When I click on \"continue\" I\'m getting a crash, but I\'m definitely getting there.


____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Schik wrote:
Well, I got to the point where the spinning heads come up. When I click on \"continue\" I\'m getting a crash, but I\'m definitely getting there.

Wow! You got momentum. Go Schik Go!

-Erik


____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

mrimer
Level: Legendary Smitemaster

Rank Points: 5056
Registered: 02-04-2003
IP: Logged

Schik wrote:
Well, I got to the point where the spinning heads come up. When I click on \"continue\" I\'m getting a crash, but I\'m definitely getting there.

This is definitely cool. So, once we have a working Irix port, then what else needs to be done to port to Unix?

(This would definitely qualify as one of the top Unix games out there.)

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

mrimer wrote:
This is definitely cool. So, once we have a working Irix port, then what else needs to be done to port to Unix?

(This would definitely qualify as one of the top Unix games out there.)

By the way, I actually played through a couple of rooms last night! I would have played more, but I was running it remotely so it was s...l...o....w......

What would be ideal is to make an autoconf script so that for any Unix, you can just run configure and make and it works. However, we\'re somewhat limited to our choices of OS due to fmod only being available for Win32, Linux, and Mac. So I would probably just make a Makefile.sgi and someone who has Linux can make any modifications needed.

So basically, we still need somebody to port it to Linux. However, that should be much much easier after I\'ve got my changes checked in.



____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

I didn\'t have much time to play with this today. I did go ahead and play through the first level, and got through it without crashes. However, when I went on the stairs, it told me I won the game. I guess DROD is just a lot easier on an SGI.


____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

Schik
Level: Legendary Smitemaster

Rank Points: 5381
Registered: 02-04-2003
IP: Logged

I\'m having a little problem...

I created a fresh drod1_5.dat with DRODUtil. Then I start DROD, start the first level, then quit. I start DROD again, continue, and the room is all black. Beethro and the door look fine, but all the normal room tiles are just black.

If I start it again, it\'s fine. I start it again, it\'s not. Every other time it\'s fine. Sounds like a big/little endian problem to me - something getting converted back and forth. So I put some debugging in CRoomWidget::Repaint that basically prints out what tile # is being painted at each position. Every run, the output is the exact same.

Also, the mini-map always looks correct - so it certainly seems to be loading the data correctly.

Any thoughts, ideas?



____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi