SDL 1.1.7 and svgalib problems

Any trick how I can rebuild the library faster? Just make didn’t build a
new library, I must make “make clean; make install”.

make changed

  1. SDL with svgalib has a very fast mouse cursor.
  The mouse cursor moves the half screen, if I only touches the
  mouse. FreeCraft with its own svgalib driver works fine, but I
  set the mouse scale self with mouse_setscale(1) and divide the
  mouse moves through 15.
  If I disable in  /etc/vga/libvga.config the acceleration
  (mouse_accel_type off) my program works with SDL fine.

As mentioned before, SDL is just reporting the raw values given to
it by SVGAlib, respecting the user preferences. You probably shouldn’t
have acceleration defined in libvga.config

Perhaps a point for the FAQ.

nod

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Lutz Sammer wrote:

Sam Lantinga wrote:

I have tested freecraft with SDL 1.1.7 and found following problems.

  1. SDL with svgalib didn’t restores termios
  After running, I must make "stty sane" to restore my terminal
  settings. FreeCraft with its own svgalib driver works fine.

I’ll take a look…

I don’t see any difference between the FreeCraft SVGAlib cleanup code
and the SDL SVGAlib cleanup code. Both perform vga_setmode(TEXT) followed
by keyboard_close(). I can’t get SVGAlib to work with my G450, so I can’t
debug this myself. Any ideas?

I have searched for the bug, but I didn’t found it.
But I have found that with testwin, the keyboard terminal setting is destroyed,
with testkey not.

Any trick how I can rebuild the library faster? Just make didn’t build a
new library, I must make “make clean; make install”.

I will look more.

Here is a patch, that let svgalib better working.

Bye,
Johns–
Become famous, earn no money, create music or graphics for FreeCraft

http://FreeCraft.Org - A free fantasy real-time strategy game engine
http://fgp.cjb.net - The FreeCraft Graphics Project
-------------- next part --------------
Index: src/video/svga/SDL_svgavideo.c

RCS file: /cvs/SDL/src/video/svga/SDL_svgavideo.c,v
retrieving revision 1.1.2.7
diff -u -r1.1.2.7 SDL_svgavideo.c
— src/video/svga/SDL_svgavideo.c 2001/01/30 05:18:05 1.1.2.7
+++ src/video/svga/SDL_svgavideo.c 2001/01/30 21:38:57
@@ -239,6 +239,7 @@
SDL_SetError(“Unable to initialize SVGAlib”);
return(-1);
}

  • vga_setmode(TEXT);

    /* Enable mouse and keyboard support */
    vga_setmousesupport(1);
    @@ -336,7 +337,7 @@

#if defined(linux)
/* Since SVGAlib 1.40 leaks the mouse here, we have to close it */

  • mouse_close();
  • //mouse_close();
    #endif /* linux */

    /* Try to set the requested linear video mode */

Using select() is inherently non-portable. You shouldn’t rely on the
SDL timer to interrupt anything. If you need for the select() to be
interrupted periodically, you may want to set the timeout value in the
select() call explicitly, or use setitimer() directly.

There are several reasons why SDL doesn’t use select() internally.
One is that X protocol transactions trigger the select() call and
another is because select() doesn’t handle the case where the user
is adding user-defined events from a different thread.

johns and I had a discussion about this in #sdl, and I’ve come to the
conclusion that at least part of the event system should be taken out and
shot. What would be nice to have:

a) be able to be notified by the readiness of a file or socket descriptor
b) do WaitEvent with a timeout (or, equivalently, request a "time event"
to be posted at a given time)

SDL_WaitEvent() does something terrible — if there is no event in the
queue, it unconditionally sleeps 10 ms and polls again. This means it’s
only usable for non-real-time use

We could very well use select() or poll() internally if we take care to
include all relevant file descriptors (including the X11 descriptors). The
problem of waking up when an event is posted from another thread can be
solved by either sending a signal (causing select() to return with EINTR)
or by using a pipe. The latter might be preferable since the semantics
of signals and threads make things hazardous

johns and I had a discussion about this in #sdl, and I’ve come to the
conclusion that at least part of the event system should be taken out and
shot. What would be nice to have:

a) be able to be notified by the readiness of a file or socket descriptor
b) do WaitEvent with a timeout (or, equivalently, request a "time event"
to be posted at a given time)

Just to explain the rational behind the design, UNIX is the only platform
on which you can wait for nearly every type of event with a single call.
All other platforms require that you poll several different sources of
events. In order to simplify the design and have consistent behavior
for all platforms, I used a single modest polling loop for events.

Of course that’s not to say we can’t experiment with other designs in 1.3. :slight_smile:

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software