GTK+ or SDL conversion

Discuss Chaos Strikes Back for Windows and Linux, an unofficial port of Chaos Strikes Back to PC by Paul Stevens, as well as CSBuild, an associated dungeon editor.

Moderator: Zyx

Forum rules
Please read the Forum rules and policies before posting.
Post Reply
User avatar
Paul Stevens
CSBwin Guru
Posts: 4100
Joined: 8-Apr-01 16:00
Location: Madison, Wisconsin, USA

GTK+ or SDL conversion

Post by Paul Stevens » 11-Feb-12 15:46

**Discussion continued from Conflux forum**


I have neither the time nor the inclination
to start over with a new user interface. I looked
at the GTK+ download site:
You will need the GLib, cairo, Pango, ATK, gdk-pixbuf and GTK+ developer packages to build software against GTK+. To run GTK+ programs you will also need the gettext-runtime, fontconfig, freetype, expat, libpng and zlib packages.
.....
.....
It is possible to use these packages also with Microsoft's compiler. However, [it is difficult!]
Talk about instant turn-off! I dislike very much these long
lists of dependencies.

Moreover, it says nothing about Windows CE.....it does
say it won't work on older versions of Windows.

I was careful when writing CSBwin to make any and all
operating system interactions very clear and isolated
to a very small piece of the code. It was converted to
run on the macintosh without too much trouble. It
should be no more trouble to convert it to Linux.

If I wanted to convert it to SDL, I think I could do it
in a very straight-forward way. I don't want to do that
right now. The current problem is that the Linux version
does not implement overlays. That is because the
conversion took place one layer too deep - not at the
obvious place that I had provided. This happened
because of the assembly code, in my opinion...I did
not do the conversion and was not told why this took
place. But I am willing to help.

If someone wants to convert CSBwin to use GTK+
(for Linux only or, better yet, for all operating
systems) then I wish them all the best and I promise
to assist. My initial assistance will be to rid
screen.cpp of all assembly language. Further
assistance probably will amount to explanation of
the workings of the OS interface and perhaps some
tweeking of the code to make conversion go more
smoothly. I did this with the people who originally
did the macintosh and Linux conversions. It all
went very well and we got it done. In my opinion,
conversion in this manner, although it is perhaps not
as beautiful as the 'totally-platform-independence'
conversion, would actually require less work.
Certainly less work on my part, an important
consideration.

For a Windows version I insist on the following:
The program shall consist of a single executable
file. No additional libraries will be needed for
the average Windows user. No installation shall
be necessary. Installation shall amount to copying
the executable to some mass-storage device.
Double-click and it runs. Of course, anyone can
make a Windows version that breaks these rules,
but I won't support them.

User avatar
Paul Stevens
CSBwin Guru
Posts: 4100
Joined: 8-Apr-01 16:00
Location: Madison, Wisconsin, USA

Re: GTK+ or SDL conversion

Post by Paul Stevens » 11-Feb-12 23:16

Late afternoon update.

My son dropped in with his Linux laptop.
I wrote a small folder onto a pen-drive with
Conflux. He ran it right off the pen-drive
using Wine. Worked perfectly! The
DirectX sound worked perfectly. Ran it
in 4x mode and full screen window.

His laptop is rather old.....1GB memory
and 1GHz processor. Standard Ubuntu.

A man would be silly to spend part of his life
converting a program to run on Linux when
it works so well already.

But, of course, a man would be a fool to convert
an Atari program to Windows when it runs so well
already using an emulator. :oops:

User avatar
Bit
Mon Master
Posts: 1021
Joined: 3-Mar-08 09:53
Location: Nuts trees

Re: GTK+ or SDL conversion

Post by Bit » 12-Feb-12 05:28

The last two months I needed a pause from the DM2-things (which are still in work - but - ... veeery relaxed).
So I came around two other things. The one thing done in C++, the other in C.
The C++-program used wxWidgets and FLTK.
Problems: FLTK looks pretty ugly, wxWidgets is really complex, and ending that program resulted in hundreds of memory leaks-warnings from wxWidgets. The library itself is still supported, but I have the light idea that it's overcomplex and the developers have a bigger buglist.
For the C-program:
Uses either GTK or SDL. Can't say much about SDL (haven't tried, the default library is GTK).
But: GTK is absolutely slow! Maybe a small menu-framework with one screen that is not necessary filled by GTK itself doesn't require speed - for that I don't know enough about the library.

I do have a surprising suggestion: Allegro.
You can do all hardware things with it, and there's also a simple GUI given with it.
And there's also the option to upgrade to AllegroGL when Rasmus' GL version should move to Linux too.
Allegro is the library used by DSB - maybe Sophia has a light idea how to bring CSB that way.
At least I can say that my DM/CSB-clone works very fine with Allegro (but has no menu-framework).

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

Re: GTK+ or SDL conversion

Post by Christoph » 16-Feb-12 02:08

I've never tried running the Windows version under Wine, because the native one should be faster and "eat" less resources in theory. We should bear in mind that the Linux version also works on tablet computers and Linux smart phones with ARM processors, while Wine is strictly bound to x68 processors, because it doesn't emulate a virtual machine, it only "translates" library function calls.

I can confirm that there is a "LinScreen.cpp" file that apparently re-implements the Windows screen output stuff. This one uses SDL, as well as GTK+ 1.2 (for a separate menu window only where you can change trace options and such things.) I think there haven't been substantial updates to the Linux version since quite a few years ago, just a number of bugs and incompatibilities got fixed to make it run again. This gives an impression of a sort of patchwork to me, not as if there was a clean design. I haven't dug deep, though.

If something is changed, it should be really worth the effort, I think.
Christoph

User avatar
Paul Stevens
CSBwin Guru
Posts: 4100
Joined: 8-Apr-01 16:00
Location: Madison, Wisconsin, USA

Re: GTK+ or SDL conversion

Post by Paul Stevens » 16-Feb-12 02:44

Paul Stevens wrote:If someone wants to convert CSBwin to use GTK+
(for Linux only or, better yet, for all operating
systems) then I wish them all the best and I promise
to assist. My initial assistance will be to rid
screen.cpp of all assembly language. Further
assistance probably will amount to explanation of
the workings of the OS interface and perhaps some
tweeking of the code to make conversion go more
smoothly.
Allow me to repeat that offer. It has been done
before and perhaps now is the time to do it right.
We already took care of the big/little-endian and
multi-byte word alignment problems. Those were
some nasties.

Ful Ir
Novice
Posts: 28
Joined: 26-Jan-11 20:04

Re: GTK+ or SDL conversion

Post by Ful Ir » 3-Mar-12 13:47

When I ported CSBwin to the Pandora I rewrote a good part of Linscreen.cpp to add support for the overlay graphics and also fixed up the handling of the fullscreen mode (the mouse cursor had offset problems, also on PC).
I removed the hermes library support for non-integer scaling though after visiting its homepage and getting the impression it was not very well maintained and so would present additional work to get it compiled for the Pandora. On that platform I would have tried to use OpenGL for scaling if I wanted/needed it.
I don't remember right now if I translated the assembler functions or if I rewrote them in C, maybe both. The best way to get rid of them would probably be getting rid of the Atari packed pixel screen format...ah well, one can dream. Maybe I would try it if I knew the main game code does not depend on it, but I don't know for sure.

On the topic of GUI toolkits:
I wrote the launcher application for the Pandora port in PyGTK (Python interface to GTK) and found it surprising how much work it is to create a listbox with some text lines in it. Used with C I dislike the casting of pointer types required almost everywhere (I only know that from some examples).
Maybe it also requires installation to work on windows, but I'm not sure.

On the other hand I would like to throw Qt into the mix, which I am using professionally on both embedded Linux and Windows (so yes, I'm biased ;) ). It also supports MacOS, but I have no experience with that.
It should easily do the GUI, graphics and input stuff required for CSBwin; you can also use OpenGL with it if you want. It works with either GCC or the Microsoft compiler on windows and GCC on the other platforms. No code changes required.
Its support for sound is limited, but it can stream raw sample data to an audio device, which should be sufficient. For multiple samples to play at once the application must mix them together itself, but CSBwin does this anyway, on Linux at least.
Another small drawback: Qt requires the build system to run an additional compiler-like tool called moc to create data structures for its meta-object system; it supplies its own cross-platform tool qmake to do this. On Linux CSBwin currently uses cmake as its build tool which also supports Qt. I do not know how easy it is to get it to work with MSVC, but CSBwin has not very many GUI-related sources anyways so it could probably even be added manually to the project file.
Running an application built with Qt on Windows does not require installation, you can just unzip and run it. The windows version of the SDK ships together with GCC so you do not have to install anything else to work with it (when using qmake as a build tool).
It is licensed under LGPL, same as GTK.

Regarding the Windows CE port, I cannot know how important it is/how many people use it, but I would say it is impossible to find something that works on CE and other platforms except the Win32 API (and of course having CSBwin do the GUI stuff itself...).

So now I think I have bored you enough with my smartass comments... :wink:.

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

Re: GTK+ or SDL conversion

Post by Christoph » 3-Mar-12 14:23

Ful Ir wrote:When I ported CSBwin to the Pandora I rewrote a good part of Linscreen.cpp to add support for the overlay graphics and also fixed up the handling of the fullscreen mode (the mouse cursor had offset problems, also on PC).
I removed the hermes library support for non-integer scaling though after visiting its homepage and getting the impression it was not very well maintained and so would present additional work to get it compiled for the Pandora. On that platform I would have tried to use OpenGL for scaling if I wanted/needed it.
Sounds interesting, is there any reason, why your modified version should not run on x86?
Ful Ir wrote:Its support for sound is limited, but it can stream raw sample data to an audio device, which should be sufficient. For multiple samples to play at once the application must mix them together itself, but CSBwin does this anyway, on Linux at least.
Does it? The sound appears „stacked“ here (using ESD), and it will „overflow“ at some point and stop after that.
Christoph

Ful Ir
Novice
Posts: 28
Joined: 26-Jan-11 20:04

Re: GTK+ or SDL conversion

Post by Ful Ir » 3-Mar-12 16:41

No, the modified screen driver works on x86 as well. I currently do not remember if I broke anything besides the hermes support (maybe some scaling sizes like x3 and x4). I'm going to check it, but this will take a couple of days. If anyone of you wants to take a look, the modified version can be viewed here. (Downloads are currently not possible, sorry).

With sound I never tried the ESD version, I do not remember the other options available, but I rewrote it with direct ALSA output using SDL_mixer for the Pandora. Sorry I got this mixed up with some other project I did where I wrote the software mixer myself.
This also works on x86. The code is not very robust though, for a proper PC-side release it will probably need some configuration options like sound device name and buffer size added.

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

Re: GTK+ or SDL conversion

Post by Christoph » 3-Mar-12 22:25

Hi,

I previously assumed that the huge size difference between the Armel and x86 "LinScreen.cpp" was due to hardware platform differences, but as it turns out now, this is merely commented out old code and replacements implementing the overlays.

Simply replacing the file in my source tree resulted in the following errors:

Code: Select all

LinScreen.cpp: In function »void UpdateScreenArea(i8*, SDL_Surface*, i32, i32, i32, i32, i32, i32, tPaletteColor*, bool, i32*, i32, bool)«:
LinScreen.cpp:1206: Fehler: »i16*« kann nicht nach »ui32*« in argument passing umgewandelt werden
LinScreen.cpp: In function »void display()«:
LinScreen.cpp:1267: Fehler: »class OVERLAYDATA« hat kein Element namens »m_colorFormat«
LinScreen.cpp:1268: Fehler: »CF_RGB888« is not a member of »OVERLAYDATA«
LinScreen.cpp:1268: Fehler: »CF_RGB565« is not a member of »OVERLAYDATA«
This looks rather promising, I think there isn't THAT much to do any more in order to get overlays working on x86.

Line 1206 is the end of "blitFunc", but I don't know yet which argument it is complaining about. It seems this is the non-overlay blitter?

Any hints, especially where I find those missing "m_colorFormat" and "CF_RGB*" things? I'm not fond of downloading every file one by one until I find the correct one(s), as you said that downloading is impossible…
Christoph

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

Re: GTK+ or SDL conversion

Post by Christoph » 3-Mar-12 22:34

One more thing probably worth to mention:

I recently tried to run the Maemo version 11.059 on my N810. It crashed with "illegal instruction" (like many programmes do, when upgraded to "current" versions.) It seems that the Maemo community is unable/unwilling to take into account that the N770/N800/N810 are not the N900 and thus cannot run "Fremantle", they keep destroying my "sources.list".

It should be easy to compile versions for Diablo or Chinook, though. Apart from the processors' instruction sets and the screen sizes there shouldn't be substantial differences.
Christoph

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

Re: GTK+ or SDL conversion

Post by Christoph » 3-Mar-12 22:55

Ful Ir wrote:With sound I never tried the ESD version, I do not remember the other options available, but I rewrote it with direct ALSA output using SDL_mixer for the Pandora. […]
This also works on x86. The code is not very robust though, for a proper PC-side release it will probably need some configuration options like sound device name and buffer size added.
The only other option on Linux (x86) is redirection through a pipe. How do I use that SDL_mixer parts? I think it is likely to be a huge improvement to merge this into the x86 source rather than relying on Esound there, which is considered deprecated even on Debian. SDL is needed anyway, so it won't have more dependencies than before, I think (maybe even less).

I'm now rather confident that we can get proper sound and overlays/shaking screen on all Linux ports without too much work. It should even be possible to make a Linux version which is in fact independent of the hardware platform. I suggest to attempt that first, and derive any future better/more platform independent stuff from such a re-unified version rather than beginning a re-implementation with QT or whatever.
Christoph

User avatar
Paul Stevens
CSBwin Guru
Posts: 4100
Joined: 8-Apr-01 16:00
Location: Madison, Wisconsin, USA

Re: GTK+ or SDL conversion

Post by Paul Stevens » 3-Mar-12 23:16

Great work you two are doing.
When you get that 'Platform-independent'
version working.........I hope.....then I
think I will try to incorporate it back into the
Windows version. I'm happy using SDL
and SDL_Mixer if they work well. I have
used SDL only on one, very small project
that I wanted to work on both Windows
and Puppy Linux. It was successful.

I would like to provide a way to change menu
options within the game, even if it is very
ugly. Some debugging is very dependent
on such shenanigans. But I don't think it
is worth a large additional library.

Ful Ir
Novice
Posts: 28
Joined: 26-Jan-11 20:04

Re: GTK+ or SDL conversion

Post by Ful Ir » 4-Mar-12 22:05

I have put up the source code for download (including the git repository, if you do not want it just delete the ".git" directory after unpacking) here.

The CF_RGB888 and m_colorFormat are defined in CSB.h and graphics.cpp. This is the commit first adding these variables. I also updated WinScreen.cpp accordingly, but didn't test it if I made any mistakes.
The problem was that on PC the frame buffer is usually in 32 bit color depth and on the Pandora it is 16 bit.

The error in line 1206 you're getting refers to argument #5 "palette". I changed its type to ui32 to support 32bit color depth (I may be confusing some details here, I do not remember what color depth was used before I started working on it).
It now works like this: The palette entries are always created with 32 bits, for 16bit output the upper and lower 16 bits are set to identical values (so the x2/x4 zoom blitting functions can write two pixels per instruction).

Would it help you if I sorted or grouped the commits by topic (sound/graphics/etc) ? I do not know if you are used to working with patches/git and so on.
The changes needed for SDL_mixer stretch across several files so I cannot easily pin them to one or two locations.

If you want to run Conflux on a Nokia tablet or similar device you probably want to add this patch (click on "raw" near the top to get it in machine-readable format), otherwise you'll probably encounter the problem that resting the party will cause the game to become uncontrollable after a few seconds due to the SDL event queue being flooded with timer events as they occur faster than the CPU can process them.

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

Overlays working on Linux/x86

Post by Christoph » 5-Mar-12 00:22

Ful Ir wrote:I have put up the source code for download (including the git repository, if you do not want it just delete the ".git" directory after unpacking) here.

The CF_RGB888 and m_colorFormat are defined in CSB.h and graphics.cpp. This is the commit first adding these variables. I also updated WinScreen.cpp accordingly, but didn't test it if I made any mistakes.
The problem was that on PC the frame buffer is usually in 32 bit color depth and on the Pandora it is 16 bit.

The error in line 1206 you're getting refers to argument #5 "palette". I changed its type to ui32 to support 32bit color depth (I may be confusing some details here, I do not remember what color depth was used before I started working on it).
It now works like this: The palette entries are always created with 32 bits, for 16bit output the upper and lower 16 bits are set to identical values (so the x2/x4 zoom blitting functions can write two pixels per instruction).
This was very helpful. I replaced the "LinScreen.cpp" and the "Graphics.cpp" with your versions and merged the "CSB.h" (to keep the old sound handling for now) and "Timer.cpp" (Paul set a variable "kkk=" there recently, no idea what this is good for…)

I now have a working CSBwin for x86 with functional overlay, but unchanged sound, works perfectly on the underwater level of Conflux.
Ful Ir wrote:Would it help you if I sorted or grouped the commits by topic (sound/graphics/etc) ? I do not know if you are used to working with patches/git and so on.
Never used GIT actively, but I know CVS and Subversion, so I think that is unnscessary. I used "Meld" for file comparison, this allowed me to merge the above mentioned files easily. I did some editing with "Joe", but only to change the version strings.
Ful Ir wrote:The changes needed for SDL_mixer stretch across several files so I cannot easily pin them to one or two locations.
Well, I hope to locate them starting at that change in "CSB.h".
Ful Ir wrote:If you want to run Conflux on a Nokia tablet or similar device you probably want to add this patch (click on "raw" near the top to get it in machine-readable format), otherwise you'll probably encounter the problem that resting the party will cause the game to become uncontrollable after a few seconds due to the SDL event queue being flooded with timer events as they occur faster than the CPU can process them.
This probably is interesting for x86 as well. I'm sometimes unable to wake up again in Conflux (not even "Esc" is processed any more), these problems could be related. Are the oldest or newest events thrown away? Has this any influence on the gameplay?
Christoph

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

Re: GTK+ or SDL conversion

Post by Christoph » 5-Mar-12 00:28

Ful Ir wrote:The CF_RGB888 and m_colorFormat are defined in CSB.h and graphics.cpp. This is the commit first adding these variables. I also updated WinScreen.cpp accordingly, but didn't test it if I made any mistakes.
The problem was that on PC the frame buffer is usually in 32 bit color depth and on the Pandora it is 16 bit.
This means that Paul must have a look at your changes. If this is incompatible with the current Windows source code parts, we cannot use the same source tree any more on both platforms which would be very bad. The current x86 Linux source happily coexists with the Windows stuff; all differences are in platform specific files. I'd really like to keep it that way.
Christoph

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

"Overlay version" updated to CSBwin 12.3

Post by Christoph » 6-Mar-12 20:27

Paul posted a link to the 12.3 source today which prevents reaching the limits for the number of items.
I have merged this current source with the overlay changes for the Pandora now.
It turned out that I can use the "Timer.cpp" from Pauls Windows version without any changes.

However, changes to "CSB.h" are necessary:

diff 12.3/src/CSB.h src/CSB.h

Code: Select all

3a4,8
> // the "APPVERSION" string must contain uppercase characters (if any), for display with the CSB font
> #define APPTITLE  "CSBwin"
> #define APPVERSION  "12.3"
> #define APPVERMINOR "v0" /* linux-only update*/
> 
221a227,231
>   enum ColorFormat {
>     CF_RGB555,
>     CF_RGB565,
>     CF_RGB888, // 32 bit, not 24
>   } m_colorFormat;
225c235
<   i16  *m_table;
---
>   ui32 *m_table;
231a242
>   ui32 EncodeColor(ui8 r, ui8 g, ui8 b);
252a264,300
> // TODO: appropriate ifdef condition to use the pragma pack line with Transition.c
> //#ifdef ???
> //#pragma pack(1)
> //#endif
> 
> /*
> struct SNDHEAD
> {
>   i8  byte0[4];           //"RIFF"
>   i32 Size;               //  6076  // #bytes after this integer
>   i8  byte8[8];           //"WAVEfmt "
>   i32 int16;              //    16, maybe 18 if cbSize is used?
>   i16 wFormatTag;         //     1
>   i16 nChannels;          //     1
>   i32 nSamplesPerSecond;  // 11025
>   i32 nAvgBytesPerSec;    // 11025 // important
>   i16 nBlockAlign;        //     1 // 2 for 16-bit
>   i16 wBitsPerSample;     //     8
> #if 0 // TODO: add appropriate condition for platforms that need these fields
>   i16 cbSize;             //    40
>   i8  byte38[4];          // "fact"
>   i32 int42;              //     4
>   i32 numBytes46;         //
> #endif
>   i8  byte50[4];          // "data"
>   i32 numSamples54;       //
>   i8  sample58[1];
> }
> #ifdef   __GNUC__
> 	__attribute__((packed))
> #endif //__GNUC__
> ;
> */
> 
> // 'sample58' is the first sample byte so it doesn't count for the header size
> #define SNDHEAD_SIZE (sizeof(SNDHEAD) - sizeof(((SNDHEAD*)0)->sample58))
> 
267c315
<   ui32 *m_codes;
---
>   ui16 *m_codes;
3747a3796
> //RESTARTABLE _MoveParty(const i32 button); //TAG01992e (void)
4281a4331,4334
> 
> //Moved here from Transition.h:
> #define		min(a,b) (((a)<(b))?(a):(b))
> #define		max(a,b) (((a)>(b))?(a):(b))
Descritption of the differences above:
  1. Ful Ir had moved the version and name strings from "CSBlinux.cpp" to this file, which isn't strictly necessary. Sadly, programme name and version strings are still scattered all over the place, since Windows ("NT" derivatives as well as CE) uses the "CSBwin*.rc" files and "Makefile.am" contains package name strings, which are apparently unused. The "IDS_Version" in Windows is used, while the file revision is obviously stuck at "1.0.0.1" for ages.
  2. "ColorFormat" is new from tha Pandora version's overlay implementation and doesn't harm the Windows part.
  3. "i16 *m_table" is defined as "ui32 *m_table"; this difference should be removed somehow.
  4. "ui32 *m_codes" is defined as "ui16 *m_codes"; this difference should be removed somehow.
  5. I commented out the sound stuff from the Pandora version as of now. I've found sound stuff in "Transition.c" as well, which seems to be used on Windows, but not on Linux. Sound is completely different on both platforms, as it seems.
  6. I moved the definitions for "min" and "max" from "Transition.h" to this file, because the "Transition.*" are not used at all on Linux while "SmartDiscard.cpp" now needs "max", which it didn't before.
As soon as the points 3 and 4 in the list above are resolved, a Linux version with working overlays without breaking the Windows source code could be released, if I'm not mistaken. This of course affects also "Graphics.cpp":

diff 12.3/src/Graphics.cpp src/Graphics.cpp

Code: Select all

2932a2933
>   : m_colorFormat(CF_RGB555)
2950c2951
<         m_table = (i16 *)UI_malloc(8192,MALLOC078);
---
>         m_table = (ui32 *)UI_malloc(8192*2,MALLOC078);
2975a2977,3005
> /**
>  * Encode a color according to m_colorFormat.
>  * r,g,b are expected to be in the range 0-255.
>  * For the 16-bit formats, the bits are duplicated in the
>  * upper word to make it easier for the blitting functions to
>  * write two pixels at a time.
>  */
> ui32 OVERLAYDATA::EncodeColor(ui8 r, ui8 g, ui8 b)
> {
>   ui32 rgb;
>   switch (m_colorFormat) {
>   default:
>   case CF_RGB555:
>     r&=0xF8;
>     g&=0xF8;
>     b&=0xF8;
>     rgb = ((ui16)r << 7) | ((ui16)g << 2) | (b>>3);
>     return rgb | (rgb << 16);
>   case CF_RGB565:
>     r&=0xF8;
>     g&=0xFC;
>     b&=0xF8;
>     rgb = ((ui16)r << 8) | ((ui16)g << 3) | (b>>3);
>     return rgb | (rgb << 16);
>   case CF_RGB888:
>     return ((ui32)r << 16) | ((ui16)g << 8) | b;
>   }
> }
> 
2982c3012
<   i16 *pTable;
---
>   ui32 *pTable;
3014,3016c3044,3046
<             *pTable = (i16)(  ((red100[i])/800) << 10
<                             | ((green100[i])/800) <<  5
<                             | ((blue100[i])/800) <<  0);
---
>             *pTable = EncodeColor(  ((red100[i])/800) << 3,
>                             ((green100[i])/800) <<  3,
>                             ((blue100[i])/800) <<  3);
3026,3028c3056,3058
<             *pTable = (i16)(  ((red[i] + RED)/800) << 10
<                             | ((green[i] + GREEN)/800) <<  5
<                             | ((blue[i] + BLUE)/800) <<  0);
---
>             *pTable = EncodeColor(  ((red[i] + RED)/800) << 3,
>                             ((green[i] + GREEN)/800) <<  3,
>                             ((blue[i] + BLUE)/800) <<  3);
3045c3075
<         m_table[i] = (i16)(((RED & 0xf8)<<7) | ((GREEN&0xf8)<<2) | ((BLUE&0xf8)>>3));
---
>         m_table[i] = EncodeColor(RED, GREEN, BLUE);
3057,3058c3087,3089
<       m_table[i] = (i16)((RED<<12) | (GREEN<<7) | (BLUE<<2));
<       m_table[i] |= (m_table[i] & 0x6318) >> 3;
---
>       m_table[i] = EncodeColor((RED << 5) | (RED << 2),
>           (GREEN<<5) | (GREEN<<2),
>           (BLUE<<5) | (BLUE<<2));
3066c3097
<   m_codes = (ui32 *)UI_malloc(4*512,MALLOC075);
---
>   m_codes = (ui16 *)UI_malloc(2*512,MALLOC075);
3094c3125
<   m_codes = (ui32 *)UI_realloc(m_codes, 4*m_maxTableLen, MALLOC080);
---
>   m_codes = (ui16 *)UI_realloc(m_codes, 2*m_maxTableLen, MALLOC080);
3156c3187
<     m_codes[m_tableLen] = (ui32)m_a;
---
>     m_codes[m_tableLen] = (ui16)m_a;
Hence the situation is as follows: "CSB.h" and "Graphics.cpp" are different in the Windows 12.3 release and the current working Linux release with overlays added, all other source code files are either equal or specific to Windows or Linux, so don't influence the other platform.

Any ideas how to resolve this other than making a "WindowsGraphics.cpp" and a "LinuxGraphics.cpp"?
I dislike very much to let the different platforms drift further apart.
The good news is that overlays are now working flawlessly on x86 Linux (and compatible to the Pandora ARM Linux version) and that the changes to the previous Linux version are quite small.
Christoph

Ful Ir
Novice
Posts: 28
Joined: 26-Jan-11 20:04

Re: GTK+ or SDL conversion

Post by Ful Ir » 6-Mar-12 22:24

Yes, the sound code for Windows is completely separate. While adding the SDL_mixer stuff I noticed the sound output on Windows has noticeably better quality (less noise/distortion). Maybe there was some interpolation going on behind the scenes. So using SDL_mixer for Windows as well would probably be a step backwards.
The changes I made to Transition.c was just removing another definition of SNDHEAD which was defined in like 3 or four places, but those definitions were not identical, so some functions used some header data at offset X and other functions at X+2 or something like that.

I do not know if the Makefile.am is still in use at all. The version I started from had a CMakeLists.txt which seemed more up to date, so I used that with cmake. (I do not know how to really use automake and I'm quite sure I do not want to if I can avoid it ;) )

When I did the palette changes last year, Paul understandably didn't want to add unnecessary changes to the windows version. So as far as I see it, there are three options:
a) use my palette code for windows as well and test if it works
b) change the linux 32bpp output code to convert to RGB888 (from 565 or so) on the fly. This will cause a performance penalty, but for desktop systems it won't matter. Battery-powered systems will waste more CPU cycles. But the question is if these platforms will ever use the 32bpp version for the forseeable future (I assume high-end smartphones these days have 32bpp color depth, but these usually don't run linux (I don't count Android here))
c) duplicate the palette generation function into a windows and linux version like Christoph suggested. Ugly, but works.

Probably I should just try to run the windows version if I can get it to compile with VS2008 Express. Never tried yet. Does one of you know if this "just works"?
If this doesn't work out, I would favor option B.

I'm going to have a look at the new version from Paul this weekend (hopefully) and see if I can build a new Pandora version with it.

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

Re: GTK+ or SDL conversion

Post by Christoph » 7-Mar-12 00:24

I used the "autogen.sh" to compile the Linux version, and updated "src/Makefile.am" therefore to make it work again, completely ignoring Cmake which I've never used before (and I wasn't aware that this is the alternative way to build it on Linux).

The wasting of CPU cycles in b) doesn't sound good to me.
If we chose c), we could put the differing definitions into the "#ifdef _MSVC" branch.

The massive changes for the graphics part are in "LinScreen.cpp", which does not affect Windows at all and replacing the old Linux file version with your Pandora code works out of the box. The only differences between Linux and Windows regarding graphics are in said "Graphics.cpp" and "CSB.h", and there we can choose the correct version with preprocessor directives, thus use c) to avoid making it worse for handheld devices.

Perhaps Paul can say if a) is an option?

I think the best way to proceed is to merge the Pandora changes for sound and overlays into the current Windows 12.3 code (all the Linux-only parts of 12.3 are the same as in the 12.100 release); this can be done without breaking or even affecting Windows code. In the end we should have only one Linux codebase for all platforms (N900/8x0/770, Pandora, x86) containing the best of the previous versions, and differing only from Windows where it is necessary.

For overlays see above, I've an incomplete option c) working right now.
Sound was too confusing for me as of now, so I left that out; the Linux part from 12.3 is probably unchanged from the pre-Pandora version using ESD/pipes.
Last edited by Christoph on 7-Mar-12 00:41, edited 1 time in total.
Christoph

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

Translation

Post by Christoph » 7-Mar-12 00:37

I've found that the (german) language translation sort of works. If a file "Translation.txt" is present, it is loaded and scanned for replacement patterns: "ENGLISH" "WHATEVER LANGUAGE". Unfortunately item names cannot be replaced. All of the longer text parts do not work. When pressing "ESC", "GAME FROZEN" cannot be replaced and many more, such as the orange item descriptions. All of the Compass directions do work, you can display "GRUPPE SCHAUT NACH NORDEN" instead of "PARTY FACINGNORTH", for example. "UNIQUE", "FUNEREAL", "VAMPYRIC", "CURSED" (and probably also "BROKEN") are all replaceable, but not the " AND " between them when two of the properties apply. All of the character statistics and level names like "NOVICE PRIEST" are translatable, but not "FOOD" and "WATER". Does anybody know how the translation code works?

I've experimented with a german "Translation.txt" from 2008 and enhanced this, but currently I see no way to replace more than the few classes of words already working. This is not really useful right now, because 99% of the in-game texts remain english, especially as the already working translations suffer from english words being ridiculously short compared to average european languages, so there's barely enough space.
Christoph

User avatar
Paul Stevens
CSBwin Guru
Posts: 4100
Joined: 8-Apr-01 16:00
Location: Madison, Wisconsin, USA

Re: GTK+ or SDL conversion

Post by Paul Stevens » 7-Mar-12 01:30

ridiculously short
"Reasonably Short" ? ;-)

User avatar
Paul Stevens
CSBwin Guru
Posts: 4100
Joined: 8-Apr-01 16:00
Location: Madison, Wisconsin, USA

Re: GTK+ or SDL conversion

Post by Paul Stevens » 7-Mar-12 01:42

Perhaps Paul can say if a) is an option?
I am not really anxious to return to WinScreen.cpp.

I fought with that at great length. It was rewritten
several times. Confuses me every time. I would
rather have you create a LinScreen that works for
you and leave the Windows alone.
Ugly, but works.
There is a lot of that going around. If we were
starting from scratch I would feel differently. This
is a program that few people will use and not a
single one cares if the code is ugly. Also, I don't
think there will be any significant enhancements
in areas that are platform/OS dependent. Very
few enhancements ... period.

My only concern is that it work and secondly
that it can be compiled from the same set
of files. By hook or by crook.

Ful Ir
Novice
Posts: 28
Joined: 26-Jan-11 20:04

Re: GTK+ or SDL conversion

Post by Ful Ir » 13-Mar-12 07:50

A short status update:
I updated my version with Paul's changes yesterday; the merge was painless :). I gave the x86 version a small test run, no immediate crashes. I did not test the Pandora version yet; I can put it up for download though if anyone wants to try it.
I made two smaller changes: One fixed a (probably unimportant) bug where an sprintf was missing its first parameter. I do not know how likely this line is to be executed. I also added a "const" to monsterNames[] to silence some GCC warnings.
The other one is more interesting in respect to the cross-platform business; I added a macro to change the format string for 64 bit integers because gcc and MSVC use different ones, but maybe there is a better solution.

User avatar
Paul Stevens
CSBwin Guru
Posts: 4100
Joined: 8-Apr-01 16:00
Location: Madison, Wisconsin, USA

Re: GTK+ or SDL conversion

Post by Paul Stevens » 13-Mar-12 14:09

Ful Ir wrote:I made two smaller changes:
Thanks. I have included your changes in
my source code.

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

Re: GTK+ or SDL conversion

Post by Christoph » 18-Mar-12 04:34

Ful Ir, what does "painless" mean exactly? As I wrote earlier, I've found differences in "CSB.h", for example, while including your changes into Paul's most recent source. This means that the Windows version might be affected, or did you do your needed changes elsewhere, like moving those things out of this file into Linux-only files?
Christoph

Ful Ir
Novice
Posts: 28
Joined: 26-Jan-11 20:04

Re: GTK+ or SDL conversion

Post by Ful Ir » 21-Mar-12 22:58

No, I just meant it in respect to having few conflicts while merging into my version. I was a little afraid I would have to dig around a lot more.
I can remember one of the conflicts being the version string (which I had moved around last year) and another the definition of "unknownTime" in _SelectSaveGame(). I also changed two invocations of the max() macro to _max (which I had already defined in CSBtypes.h).
These should not change the behaviour of the windows version, and not increase the amount of differences either (except for the above mentioned _max and the two mentioned in my previous post).
I still want to try to compile my version for windows but I still haven't gotten around to it, sorry.

Ful Ir
Novice
Posts: 28
Joined: 26-Jan-11 20:04

Re: GTK+ or SDL conversion

Post by Ful Ir » 2-Apr-12 06:50

I compiled my version for Windows and gave it a short test, the changes I made to winscreen.cpp for ColorFormat and the type change of "palette" to ui32* appear to work correctly so far. All zoom levels in windowed mode work.
Fullscreen works as well, but I only tried one resolution yet. There is still the bug that the overlay graphics also display over the inventory screen, but this needs only one extra if condition, going to fix that later today. Also going to test different fullscreen resolutions.
Are there any special circumstances that have caused problems with the graphics output in the past that I should specifically test for?

Christoph
Craftsman
Posts: 102
Joined: 19-Nov-11 23:04

Re: GTK+ or SDL conversion

Post by Christoph » 2-Apr-12 17:29

At least in the Linux version the behaviour when picking up and holding an item is weird: the mouse cursor always has the shape of the item, but is coloured in cyan when held over the "world window"; it is couloured correctly over the characters' hands area and in the whole inventory screen. If you move an item partially over a character's hand or the statistics bars and partially above the dungeon screen, the part over the dungeon window is uniformly coloured in cyan (no structure can be seen, it's all in one coulour), the other part of the item looks normally.

Paul had also implemented an additional statistics display for 1x screen size (which is rather tiny in windowed mode), this feature doesn't exist in the Linux version at all.

If you see a simple way to change either of those, so that picked up items are always shown normally and that the statistics display is available on any platform and screen size, I'd appreciate it.
Christoph

User avatar
Paul Stevens
CSBwin Guru
Posts: 4100
Joined: 8-Apr-01 16:00
Location: Madison, Wisconsin, USA

Re: GTK+ or SDL conversion

Post by Paul Stevens » 2-Apr-12 18:42

picked up items are always shown normally
That is the Atari way. It had to be that
way because of the limited palette. Otherwise,
the cursor would disappear when the dungeon
became dark. That is why the controls are
all the same color, too! They are on the same
scan-lines as the viewport.

Post Reply