r.Q

Quote: Originally written by Ormus: Quote: Originally written by Reve: Just wondering, why not put them into a directory as separate sound files? Then people can much more easily remove/replace individual sounds. Because I don't know how to load sounds from files using Windows API only. In the future I am going to add support for external files, but now I have other priorities. Hey Ormus ! I have something for You;) I've rewritten all sound engine. Now it reads sound data from external *.WAV files, uses 32-bit Windows Multimedia function, and locks global handles only when playing sound (in order to avoid memory fragmentation). Following archive indludes two files: EXLSOUND.CPP and EXLSOUND.H. I have added "delete_all_sounds" function, to release all allocated memory, so You should call this function in course of processing "WM_DESTROY" message. Archive: Download here I hope You find it useful. Regards

Hi;) I would like to share some of my observations resulting from my work on BoE open source code. I use Dev-C++ compiler and at this moment code is compiling and running, but it wasn't easy. During my work, I have found some strange errors, like unexpected program collapsions, or terminations. To find out, what's going wrong I have spent a lot of time on debugging. I hope this post will save some time to people who have found similar problems. First obstacle was an unexpected program collapsion while showing dialog box window. The reason of this situation is incorretly string formatting in "dummy_dialog_proc" (DLOGTOOL.CPP file) dialog window procedure. As we can see in line 616: Code: [...]else sscanf(item_str,"%d_%d",&type,&flag);[...] 'type' and 'flag' variables has 'short' type, while formatting string ("%d_%d") describes 'long' types. Properly, formating string should be "%hd_%hd". Next thing is program terminiation, while closing dialog box windows. That was very frustrating, because everything seems to be OK. In this situation something is littering our application message queue with WM_QUIT message. Problem lies in implementation of "fry_dc" function (GRAPHUTL.CPP file, line 612). The solution is to rewrite this function to something like this: Code: void fry_dc(HWND hwnd,HDC dc) { if(!ReleaseDC(hwnd, dc) && !DeleteDC(dc)) PostQuitMessage(0);} Ok, that's all what I have to say (now;)). Hope that anybody find it useful.Bye;)

Quote: Originally written by Ormus: Compiler used by Jeff didn't align data in structures to memory addresses divided by 2 or 4 because it wasn't important years ago to do it. But my compiler does align data in structures and this changes values of all the sizeof's used to measure length of data blocks to read or write. I suppose that other modern compilers may do that. Unfortunately, I couldn't find how to turn off this thing, so I had to rewrite some portions of FILEIO.CPP in a very ugly way. Now it is loading save-games correctly. There is a way to turn off structure data align on the GCC based compiler (e.g Dev-C++). To do it, You have to add "__attribute__" instruction to a structure definition. For example: Code: typedef struct#ifdef __GNUC__ __attribute__ ((packed)) #endif{ char a; int b;} NOT_ALIGNED_STRUCTURE; Anyway, this is not recommended but it's worth to know

Beeps... I mean BoE od course Thanks!

Hi:) If You want to make code more compatible with Win32, You should rewrite all file I/O functions. You should use CreateFile instead of OpenFile functions, SetFilePointer instead of _llseek, etc. BTW there is no TINYOBJ.BMP file in Windows release of EoB source code. You can get it from shareware version of EoB.