On event system and non-video apps

now I realize that this may not be a -portable- possibility, but is it
possible to activate/use the SDL event system without requiring graphics
to be initialized? The keyboard/mouse/joystick/… handlers are -sooo-
useful but I’m working on a text based program right now… heh

ideas?

I’m quite aware it might not be possible - and even though textmodes are
on the decline, some platforms still use them :slight_smile:

G’day, eh? :slight_smile:
- Teunis (Tony) Peters

I’m quite aware it might not be possible - and even though textmodes are
on the decline, some platforms still use them :slight_smile:

…and more importantly, sometimes I’m not in X, and I want stdio output.

I wonder how hard it would be to cobble together a few SDL drivers: the
dummy video and some of fbcon, so that you can get an SDL interface to
mouse/keyboard/etc without needing to actually initialize a real video
mode…

And yeah, the use is somewhat limited, but it could be interesting.

–ryan.

I’ve used SDL and SDL_image in “pure” console applications (although not
with any UI but the command line args), and it might also be useful for
combined game servers and clients and that kind of stuff.

BTW, I have a somewhat related problem with Kobo Deluxe: Non-console
users can’t see the stdout and stderr output from the game, so it just
seems to “do nothing at all” if you start it without the images in place,
for example. Providing a console window that can be called up on any
platform would make serious multiplatform support lot easier, and seems
slightly related to the above. (The console window could be implemented
on top of this “system console drivers”.)

As to the video output; how about adding a real text console driver that
applications can optionally use instead of the dummy driver? Not AAlib -
what I’m talking about is a lowres 8 bit (or 16 bit unicode, or 24 bit
unicode + color…) mode, where each “pixel” is in fact a character.
SDL_Flip() would scan the buffer for changes and update the console
accordingly. Could be a nice tool for creating advanced but portable text
mode user interfaces.

Could also take some time to implement! :slight_smile: Would AAlib or some other
text related library contain useful stuff, and if so, what about
portability? (Un*x consoles, Win32 console etc. Targets without a console
would have to use a built-in console emulator or something.)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Tuesday 18 September 2001 13:49, Ryan C. Gordon wrote:

I’m quite aware it might not be possible - and even though textmodes
are on the decline, some platforms still use them :slight_smile:

…and more importantly, sometimes I’m not in X, and I want stdio
output.

I wonder how hard it would be to cobble together a few SDL drivers: the
dummy video and some of fbcon, so that you can get an SDL interface to
mouse/keyboard/etc without needing to actually initialize a real video
mode…

And yeah, the use is somewhat limited, but it could be interesting.

As to the video output; how about adding a real text console driver that
applications can optionally use instead of the dummy driver? Not AAlib -
what I’m talking about is a lowres 8 bit (or 16 bit unicode, or 24 bit
unicode + color…) mode, where each “pixel” is in fact a character.
SDL_Flip() would scan the buffer for changes and update the console
accordingly. Could be a nice tool for creating advanced but portable text
mode user interfaces.

Are you talking about a text-based framebuffer, or adding an actual
console API?

–ryan.

Both, as applicable on a per-platform basis. (Not all hardware has text
modes - and not all targets have “text windows” I guess.)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 20 September 2001 10:33, Ryan C. Gordon wrote:

As to the video output; how about adding a real text console driver
that applications can optionally use instead of the dummy driver? Not
AAlib - what I’m talking about is a lowres 8 bit (or 16 bit unicode,
or 24 bit unicode + color…) mode, where each “pixel” is in fact a
character. SDL_Flip() would scan the buffer for changes and update
the console accordingly. Could be a nice tool for creating advanced
but portable text mode user interfaces.

Are you talking about a text-based framebuffer, or adding an actual
console API?

Note: (repeating a comment below) not even SDL_Quit works when the
videosystem isn’t active… I personally feel this is a bug!
(mind you I haven’t traced the code yet… hrm… later today after work :slight_smile:
I could cobble my own key handler together if -any- of the event system
were operational under the console but -none- of it is!!!

although kicking in the dummy video driver allowed my code to work…

I’m quite aware it might not be possible - and even though textmodes
are on the decline, some platforms still use them :slight_smile:

…and more importantly, sometimes I’m not in X, and I want stdio
output.

[clip]

on SDL and a console present:
SDL_Console works fairly well and while it needs a lot of tuning
to match the linux console and can’t be accelerated the way the
linux console is (due to the lack of accelerated sprites)…
(umm it’s more complicated than that I’m oversimplifying :slight_smile:

on SDL and stdio support:
What would it take for SDL on systems that have it to use the
console present with events active? It’d be a snap under linux…
well except for X. and Windows doesn’t have a console most of the
time. MacOS <=9 doesn’t, but MacOS X does… hrm…

I think this is desireable

hrm… I still can’t think of a portable way to do it though…

on SDL and textmode console driver:

As to the video output; how about adding a real text console driver that
applications can optionally use instead of the dummy driver? Not AAlib -
what I’m talking about is a lowres 8 bit (or 16 bit unicode, or 24 bit
unicode + color…) mode, where each “pixel” is in fact a character.
SDL_Flip() would scan the buffer for changes and update the console
accordingly. Could be a nice tool for creating advanced but portable text
mode user interfaces.

Useful - quite duable too. Any other thoughts here?

I’ve written console emulators a number of times - in svgalib, in GGI, in
graphics hardware under DOS (and linux later), and started porting them
to SDL… The big prob I have is while a fully linux-compatible console
is quite duable it’s hard to make one without using linux code :slight_smile:

It’s no big deal really. but what I’m looking for is not to go to an
incredibly -slow- text emulator but to use the resources present and have
the event system working.

G’day, eh? :slight_smile:
- Teunis (Tony) PetersOn Tue, 18 Sep 2001, David Olofson wrote:

On Tuesday 18 September 2001 13:49, Ryan C. Gordon wrote:

Note: (repeating a comment below) not even SDL_Quit works when the
videosystem isn’t active… I personally feel this is a bug!
(mind you I haven’t traced the code yet… hrm… later today after work :slight_smile:
I could cobble my own key handler together if -any- of the event system
were operational under the console but -none- of it is!!!

although kicking in the dummy video driver allowed my code to work…

Yes, since most of the events in SDL are tied to the video subsystem,
the event loop only kicks in if you have a video driver enabled. Using
the dummy video driver for this is the right way to do it.

This will not be a limitation in the SDL 1.3 rewrite.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment