Page 3 of 3

Re: Porting/updating CSBwin for Linux and sound support

Posted: Sun May 22, 2016 7:10 pm
by Paul Stevens

Re: Porting/updating CSBwin for Linux and sound support

Posted: Mon May 23, 2016 7:10 pm
by ChristopheF
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).

Re: Porting/updating CSBwin for Linux and sound support

Posted: Wed Jun 01, 2016 11:20 am
by vanfanel
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?

Re: Porting/updating CSBwin for Linux and sound support

Posted: Wed Jun 01, 2016 10:04 pm
by Paul Stevens
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.

Re: Porting/updating CSBwin for Linux and sound support

Posted: Thu Jun 02, 2016 12:55 am
by vanfanel
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?

Re: Porting/updating CSBwin for Linux and sound support

Posted: Thu Jun 02, 2016 1:41 am
by Paul Stevens
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. ;-)

Re: Porting/updating CSBwin for Linux and sound support

Posted: Thu Jun 02, 2016 1:49 pm
by vanfanel
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.

Re: Porting/updating CSBwin for Linux and sound support

Posted: Thu Jun 02, 2016 3:45 pm
by vanfanel
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:

Code: Select all

  textureRect.x = 0; 
  textureRect.y = 0; 
  textureRect.w = width;
  textureRect.h = height;
But you need to do:

Code: Select all

  textureRect.x = dstX; 
  textureRect.y = dstY;
  textureRect.w = width;
  textureRect.h = height; 
..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:

Code: Select all

  rendererRect.x = dstX;
  rendererRect.y = dstY;
  rendererRect.w = width;
  rendererRect.h = height;
  SDL_RenderCopy(sdlRenderer,
                 sdlTexture,
                 &textureRect,
                 &rendererRect);

...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:

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);

As you can see, the "partial update" rect we used before does not belong to the SDL_RenderCopy() call.
Anyway, you can simply do:

Code: Select all

  SDL_RenderCopy(sdlRenderer,
                 sdlTexture,
                 NULL,
                 NULL);
..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.

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;
}

Thanks!

Re: Porting/updating CSBwin for Linux and sound support

Posted: Thu Jun 02, 2016 4:39 pm
by Paul Stevens
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.

Re: Porting/updating CSBwin for Linux and sound support

Posted: Thu Jun 02, 2016 9:02 pm
by vanfanel
@Paul: Email sent :)

Re: Porting/updating CSBwin for Linux and sound support

Posted: Thu Jun 02, 2016 9:39 pm
by Magica
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?

Re: Porting/updating CSBwin for Linux and sound support

Posted: Fri Jun 03, 2016 1:32 am
by Paul Stevens
can you give me an active link?
I can give you lots of active links. But none is likely
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

Posted: Thu Jun 16, 2016 12:38 pm
by vanfanel
@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.

Re: Porting/updating CSBwin for Linux and sound support

Posted: Thu Jun 16, 2016 5:07 pm
by Paul Stevens
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.

Re: Porting/updating CSBwin for Linux and sound support

Posted: Sat Jun 18, 2016 12:45 pm
by vanfanel
@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?

Re: Porting/updating CSBwin for Linux and sound support

Posted: Wed Jun 22, 2016 1:02 am
by Paul Stevens
the mouse pointer is stuck and reapears on the new positon after a while
Here is what I tried:

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

Posted: Mon Jun 27, 2016 10:48 pm
by vanfanel
@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)?

Re: Porting/updating CSBwin for Linux and sound support

Posted: Mon Jun 27, 2016 11:00 pm
by Paul Stevens
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.