Porting/updating CSBwin for Linux and sound support
Moderator: Zyx
Forum rules
Please read the Forum rules and policies before posting.
Please read the Forum rules and policies before posting.
- Paul Stevens
- CSBwin Guru
- Posts: 4318
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
- ChristopheF
- Encyclopedist
- Posts: 1540
- Joined: Sun Oct 24, 1999 2:36 pm
- Location: France
- Contact:
Re: Porting/updating CSBwin for Linux and sound support
Work has started to port DM to the ScummVM platform (based on my ReDMCSB source code, but I don't work on the port myself): http://wiki.scummvm.org/index.php/Summe ... ter_engine
So DM might be playable on a future version of scummvm, which is available for Android (and many other platforms).
So DM might be playable on a future version of scummvm, which is available for Android (and many other platforms).
Christophe - Dungeon Master Encyclopaedia
Re: Porting/updating CSBwin for Linux and sound support
HI there,
I'd like to try to build (and release) a Raspberry Pi port of CSBWin. The Raspberry Pi is a true microcomputer, much in the vein of the microcomputers back in the Dungeon Master days, just much cheaper and smaller
So, all in all, I would like to find the SDL2 port, which I understan exists from reading another thread int this forum. Does that port build WITHOUT PulseAudio, ESD, nor GTK?
Where can I get these plan-SDL2 sources?
I'd like to try to build (and release) a Raspberry Pi port of CSBWin. The Raspberry Pi is a true microcomputer, much in the vein of the microcomputers back in the Dungeon Master days, just much cheaper and smaller
So, all in all, I would like to find the SDL2 port, which I understan exists from reading another thread int this forum. Does that port build WITHOUT PulseAudio, ESD, nor GTK?
Where can I get these plan-SDL2 sources?
- Paul Stevens
- CSBwin Guru
- Posts: 4318
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Re: Porting/updating CSBwin for Linux and sound support
http://dianneandpaul.net/CSBwin/CSBwin_SRC_20160325.zip
Is the latest source code. You can fiddle with the makefile
to use SDL1.2 or SDL2.0.
I don't know what PulseAudio is. I don't know what ESD is.
And I did not use GTK. The Linux versions are deficient in
that they have no menu. If those functions were required,
I planned to implement them via 'hot-key' sequences.
Perhaps the same simple key sequences that the Windows
menu system uses. I thought that would
make things easier to port among strange systems.
Dungeon Master, Chaos Strikes Back, and Conflux are available
for Windows, Raspberry Pi Raspian (SDL1.2), and Linux (SDL2.0) at:
http://dianneandpaul.net/CSBwin/Games/
If you can provide additional versions or games that are complete with
game demos, I would be happy to add them to the collection.
Is the latest source code. You can fiddle with the makefile
to use SDL1.2 or SDL2.0.
I don't know what PulseAudio is. I don't know what ESD is.
And I did not use GTK. The Linux versions are deficient in
that they have no menu. If those functions were required,
I planned to implement them via 'hot-key' sequences.
Perhaps the same simple key sequences that the Windows
menu system uses. I thought that would
make things easier to port among strange systems.
Dungeon Master, Chaos Strikes Back, and Conflux are available
for Windows, Raspberry Pi Raspian (SDL1.2), and Linux (SDL2.0) at:
http://dianneandpaul.net/CSBwin/Games/
If you can provide additional versions or games that are complete with
game demos, I would be happy to add them to the collection.
Re: Porting/updating CSBwin for Linux and sound support
Thanks a lot for that, Paul!
I have built an SDL2 version for Raspbian. SDL2 has specific, accelerated support for Raspberry Pi, while SDL1.x is broken and bit-rotten on this platform, causing black screen on exit on every aplication once in a while, lockups, etc.
So, all in all, SDL2 is the way to go as it uses the Pi hardware for fullscreen stretching and, given the correct SDL_CreateRendere() flags, also provides tearing-less screen updates.
So, all in all, SDL2 is the way to go with the Pi here, and SDL 2.0.4 is mature and stable.
However, CSBWin exhibits some strangeness here, as only part of the screen is visible. This is what the menu looks on the Pi with SDL2:
https://www.dropbox.com/s/sgzd61ocisu9qng/Foyv.jpg?dl=0
If I start a new game, only the navigation arrows are visible. If I move the cursor left, I can see the play area, but not the navigation arrows.
Any idea on what is going on here?
I have built an SDL2 version for Raspbian. SDL2 has specific, accelerated support for Raspberry Pi, while SDL1.x is broken and bit-rotten on this platform, causing black screen on exit on every aplication once in a while, lockups, etc.
So, all in all, SDL2 is the way to go as it uses the Pi hardware for fullscreen stretching and, given the correct SDL_CreateRendere() flags, also provides tearing-less screen updates.
So, all in all, SDL2 is the way to go with the Pi here, and SDL 2.0.4 is mature and stable.
However, CSBWin exhibits some strangeness here, as only part of the screen is visible. This is what the menu looks on the Pi with SDL2:
https://www.dropbox.com/s/sgzd61ocisu9qng/Foyv.jpg?dl=0
If I start a new game, only the navigation arrows are visible. If I move the cursor left, I can see the play area, but not the navigation arrows.
Any idea on what is going on here?
- Paul Stevens
- CSBwin Guru
- Posts: 4318
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Re: Porting/updating CSBwin for Linux and sound support
A strange looking display!
No. I have no idea what is happening. I think that you
are the expert. Not I. I did not know what I was doing
when I did it. I horsed around until it worked. I do remember
something about SDL1.2 causing lockups if it was not
closed down properly upon program exit. I tried to make
sure that did not happen.
My Raspbian did not have SDL2 installed. That is why
I used SDL1.2. And it has worked very well for me.
In any event, I would like to maintain
a version with SDL1.2. But adding an optional version
with SDL2 is a fine idea. Good luck, Expert.
No. I have no idea what is happening. I think that you
are the expert. Not I. I did not know what I was doing
when I did it. I horsed around until it worked. I do remember
something about SDL1.2 causing lockups if it was not
closed down properly upon program exit. I tried to make
sure that did not happen.
My Raspbian did not have SDL2 installed. That is why
I used SDL1.2. And it has worked very well for me.
In any event, I would like to maintain
a version with SDL1.2. But adding an optional version
with SDL2 is a fine idea. Good luck, Expert.
Re: Porting/updating CSBwin for Linux and sound support
Yeah, let's see what's going on here, Paul, but I may need some help from you in order to solve this riddle we've got here!
What does the "bitmap" array contain as it's received in UI_SetDIBitsToDevice()? Does it contain the whole screen data or ONLY the 3D-view/navigation panel data depending on what is being updated in that UI_SetDIBitsToDevice() call?
In what format are pixels in bitmap stored? 8 bit per pixel? I see it's created as "pnt bitmap" but I don't know what a "pnt" is.
I know about SDL2 but not how CSBWin works internally, so that's why I will need some clues.
What does the "bitmap" array contain as it's received in UI_SetDIBitsToDevice()? Does it contain the whole screen data or ONLY the 3D-view/navigation panel data depending on what is being updated in that UI_SetDIBitsToDevice() call?
In what format are pixels in bitmap stored? 8 bit per pixel? I see it's created as "pnt bitmap" but I don't know what a "pnt" is.
I know about SDL2 but not how CSBWin works internally, so that's why I will need some clues.
Re: Porting/updating CSBwin for Linux and sound support
Got it working right on SDL2 on the Pi, Paul!
https://www.dropbox.com/s/qet68cjzfmjcinx/Dmpi.jpg?dl=0
bitmap points partial data you use to manually (well, using memcpy) do partial updates to the texture after locking on the desired are with SDL_LockTexture().
It seems pixels are 2bytes, whatever format and the rederer is fine with it so it doesn't mind what format it is, I guess RGR565 since that's what you created the renderer with
There are a couple of problems with your code and I believe it works on windowed backends on pure luck.
1) You are setting the texture partial update rect like this:
But you need to do:
..because you want to tell SDL_LockTexture() what are the start coordinates of the partial update you want to do to sdlTexture later.
2) Later you do:
...which I believe is wrong because renderRect specifies the output size and position of the final render. You don't want to have it set to the values and position of the final updates, that makes no sense in my head.
For example, imagine you want SDL2 to hardware-scale a 320x200 image to be viewed on a 1360x768 monitor. The you would do:
As you can see, the "partial update" rect we used before does not belong to the SDL_RenderCopy() call.
Anyway, you can simply do:
..without any rects, and it will scale the renderer dimensions (320*200) to whatever the window size is. Window size is not relevant in SDL2 in a lot of systems since the window size values are ignored because we will be using fullscreen. That's the case on the Pi, where SDL2 runs without X, rendering directy on GLES2 on a dispmanx context. So, all in all, it's safe and good not to use rects here for the final SDL_RenderCopy().
Now I will include the whole modified void UI_SetDIBitsToDevice() function so you can do a new code release with this version. It doesn't present any problems on other platforms (at least X11 that I can test) and I believe it does things "the right way", if you allow me
Neededless to say, I admire every piece of your work, these are only minor corrections from an humble Pi user, Paul.
It would be good if you could leave my comments on the function for future reference.
Thanks!
https://www.dropbox.com/s/qet68cjzfmjcinx/Dmpi.jpg?dl=0
bitmap points partial data you use to manually (well, using memcpy) do partial updates to the texture after locking on the desired are with SDL_LockTexture().
It seems pixels are 2bytes, whatever format and the rederer is fine with it so it doesn't mind what format it is, I guess RGR565 since that's what you created the renderer with
There are a couple of problems with your code and I believe it works on windowed backends on pure luck.
1) You are setting the texture partial update rect like this:
Code: Select all
textureRect.x = 0;
textureRect.y = 0;
textureRect.w = width;
textureRect.h = height;
Code: Select all
textureRect.x = dstX;
textureRect.y = dstY;
textureRect.w = width;
textureRect.h = height;
2) Later you do:
Code: Select all
rendererRect.x = dstX;
rendererRect.y = dstY;
rendererRect.w = width;
rendererRect.h = height;
SDL_RenderCopy(sdlRenderer,
sdlTexture,
&textureRect,
&rendererRect);
For example, imagine you want SDL2 to hardware-scale a 320x200 image to be viewed on a 1360x768 monitor. The you would do:
Code: Select all
sourceRect.x = 0;
sourceRect.y = 0;
sourceRect.w = 320;
sourceRect.h = 200;
destinationRect.x = 0;
destinationRect.y = 0;
destinationRect.w = 1360;
destinationRect.h = 768;
SDL_RenderCopy(sdlRenderer,
sdlTexture,
&sourceRect,
&destinationRect);
Anyway, you can simply do:
Code: Select all
SDL_RenderCopy(sdlRenderer,
sdlTexture,
NULL,
NULL);
Now I will include the whole modified void UI_SetDIBitsToDevice() function so you can do a new code release with this version. It doesn't present any problems on other platforms (at least X11 that I can test) and I believe it does things "the right way", if you allow me
Neededless to say, I admire every piece of your work, these are only minor corrections from an humble Pi user, Paul.
It would be good if you could leave my comments on the function for future reference.
Code: Select all
void UI_SetDIBitsToDevice(
int dstX,
int dstY,
int width,
int height,
int,
int,
int,
int,
char *bitmap,
void *,
int
)
{
/* textureRect is for sdlTexture partial updating ONLY.
* dstX and dstY are the coordinates on which the partial update rect start on sdlTexture,
* so they must be used on textureRect accordingly.
* bitmap pixels are 2bytes each. */
SDL_Rect textureRect;
SDL_Rect rendererRect;
void *dstPixels;
int pitch;
int line;
if (sdlTexture == NULL) return;
textureRect.x = dstX;
textureRect.y = dstY;
textureRect.w = width;
textureRect.h = height;
if (SDL_LockTexture(sdlTexture,
&textureRect,
&dstPixels,
&pitch))
{
UI_MessageBox(SDL_GetError(),
"UI_SetDIBitsToDevice",
MESSAGE_OK);
die(0x53a9);
};
for (line=0; line<height; line++)
{
memcpy((ui8 *)dstPixels+pitch*line,
bitmap+2*320*(line), width*2);
};
SDL_UnlockTexture(sdlTexture);
SDL_RenderClear(sdlRenderer);
SDL_RenderCopy(sdlRenderer,
sdlTexture,
NULL,
NULL);
SDL_RenderPresent(sdlRenderer);
return;
}
- Paul Stevens
- CSBwin Guru
- Posts: 4318
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Re: Porting/updating CSBwin for Linux and sound support
Could you post the entire .cpp file (rather than this one function) somewhere?
Or email it to me? My email address is available within CSBwin's help or at
the bottom of
http://dianneandpaul.net/DianneGenealogy/
Also, you must have tweeked the makefile to compile using SDL2
on the Pi. I would like to have that.
Or email it to me? My email address is available within CSBwin's help or at
the bottom of
http://dianneandpaul.net/DianneGenealogy/
Also, you must have tweeked the makefile to compile using SDL2
on the Pi. I would like to have that.
Re: Porting/updating CSBwin for Linux and sound support
Paul
those links for dungeonmaster free on android are not vaild, everytime I try to download the game I recieve a message that it is not available to download anymore
can you give me an active link?
those links for dungeonmaster free on android are not vaild, everytime I try to download the game I recieve a message that it is not available to download anymore
can you give me an active link?
- Paul Stevens
- CSBwin Guru
- Posts: 4318
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Re: Porting/updating CSBwin for Linux and sound support
I can give you lots of active links. But none is likelycan you give me an active link?
to satisfy your need. I have nothing to do with 'dungeonmaster free'
nor with android. Nor do I know who does. If I posted links,
I found them via Google searches.
Edit:
I just tried the three links I referenced in my post of May 22.
All three worked for me.
Re: Porting/updating CSBwin for Linux and sound support
@Paul: Did you receive my mail with the updated code? I got no response so maybe you didn't it.
If you received it but had no time to answer it's ok, I only want to know if you got it so the code changes can be incorporated to the main code base.
If you received it but had no time to answer it's ok, I only want to know if you got it so the code changes can be incorporated to the main code base.
- Paul Stevens
- CSBwin Guru
- Posts: 4318
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Re: Porting/updating CSBwin for Linux and sound support
Yes, I did receive the code for LinCSBUI.cpp.
You sent it to my wife and she forwarded it to me.
I'll get around to testing and releasing it someday
when it seems that somebody will need it or I am
releasing something that makes a big difference. It is quite
a tedious chore for a small change that does not affect play.
Right now you are the only person requesting it and you
already have it.
You sent it to my wife and she forwarded it to me.
I'll get around to testing and releasing it someday
when it seems that somebody will need it or I am
releasing something that makes a big difference. It is quite
a tedious chore for a small change that does not affect play.
Right now you are the only person requesting it and you
already have it.
Re: Porting/updating CSBwin for Linux and sound support
@Paul: In that mail, I also asked you about the mouse acting strange. If I do a fast movement, the mouse pointer is stuck and reapears on the new positon after a while. Is that supposed to be normal?
- Paul Stevens
- CSBwin Guru
- Posts: 4318
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Re: Porting/updating CSBwin for Linux and sound support
Here is what I tried:the mouse pointer is stuck and reapears on the new positon after a while
I downloaded the latest Raspbian-Jessie.
Installed on a newly formated 8 GB SD card.
Booted my Pi model B with that SD card.
Plugged in my Logitec wireless mouse and keyboard.
apt-get ftp
Download DM_Raspbian_ARM-32_20151212.tar.
Extracted the files from the tar.
Executed 'play960'.
The mouse pointer seemed perfectly responsive and
smooth.
So. What is wrong? What is different?
**The Pi hardware
**Operating system
**SDL Library
**The mouse itself
**Different version of CSBwin
**Other software running simultaneously
** ???
What can you do to attempt to isolate the problem?
I can certainly get you copies of identical CSBwin and
Raspbian images if you think that one or the other
might be the problem. I could even post an image
of my SD card with CSBwin already in place. We could
call it 'Raspbian-DM'.
The only other (available) Pi I have is a Pi-2 and I could
try that if pressed.
Re: Porting/updating CSBwin for Linux and sound support
@Paul: The SDL version you are using is SDL 1.2.x, which is an outdated can of worms.
Can you build SDL2 with Pi (dispmanx+GLES renderer) support and try CSBWin built against SDL2 (outside X)?
Can you build SDL2 with Pi (dispmanx+GLES renderer) support and try CSBWin built against SDL2 (outside X)?
- Paul Stevens
- CSBwin Guru
- Posts: 4318
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Re: Porting/updating CSBwin for Linux and sound support
No. As far as I can tell it works just great with version 1.2.
If it ain't broke, I see no need to fix it. It is hard work.
I have no idea what "dispmanx + GLES renderer' means.
I thought you were going to supply a Pi version using SDL 2.0.
It is obvious that you know more about these things than I.
But I see no need for it.
If it ain't broke, I see no need to fix it. It is hard work.
I have no idea what "dispmanx + GLES renderer' means.
I thought you were going to supply a Pi version using SDL 2.0.
It is obvious that you know more about these things than I.
But I see no need for it.