In-case anyone is interested

Wondering if there’s a projects page of sorts - I think it’s nice to know
what others are owrking on sometimes (top-secret game releases not
withstanding!), however…

One of the SDL projects I’ve been working on is a BASIC interpreter
(purely as a bit of nostalgia, but who knows) so it’s been quite
interesting to try to re-create the sort of environment I used in the late
1970s-80s… (Apple II, BBC Micro, etc.)

(The other is to do with monitoring “stuff” from sensors like temperature,
pressure, and dull, boring stuff like that, however I’m now thinking that
my BASIC interpreter is actually a much nicer way to handle and display
the data than a big C program!)

SDL has been a bit of a life-saver, so a big thanks to all who work on it.
I’ve never done any graphics under a modern PC/Unix/Linux system and the
entry level to just opening a window seemed rather large until I found
SDL…

So some of the issues I’ve had is that I’ve had no control over what the
interpreter is actually executing, so no real idea when to do the
Flip/Update, other than to make some guesses - my current compromise is to
Flip when the program pauses for input (and at every character read), and
after every new line printed, and to provide a function to explicitly do a
flip/update. Issues still to be resolved is things like

PRINT "The answer is … ";
…do something that takes time
PRINT 42

with the first bit of text not being output until the newline - unless the
program explicitly calls the Flip instruction - although I did add in the
option of printing ASCII 4 (control-d) as a bit of a hack. I found that
doing an update after every single PRINT, while giving good results really
did slow it down quite a bit.

ObScreenshot:

http://unicorn.drogon.net/rtb1.png

the WAIT() call normally waits for milliseconds, but give it 0 and it does
the Flip.

I’m even toying with the same FAST/SLOW modes that the old ZX81 had - it’s
a similar sort of problem!

Although not originally on my to-do list, I want to run this on a
Raspberry Pi, so have one on order - it runs fine inside QEMU running the
Debian Pi distribution though, but the other recent posts about cross
compiling are very intersting too - to be able to procuce a Win and Mac
version without leaving the comfort of my Linux desktop is very exciting!

Other issues I’ve faced - detecting Control-C (or Escape) to stop a
running program - calling SDL_PollEvent is slow! So I need to investigate
more efficient ways of doing that - currently calling it once every 100
lines of BASIC have been executed. Maybe a separate thread to set a global
variable, who knows. (suggestions welcome, but I’ve not delved into the
whole timers/events/mask stuff in any detail yet)

And bitmap fonts? Seems to be a lot, but I’m lacking the tools to convert
them - although I have the means to convert a BMP file into a font.h array
which is what I’ve used in the past. (I don’t think an 8x8 font at 640x480
out of the Composite video connector on the RPi is going to be very
visible although software doubling it would be trivial)

Anyway there you go - thanks again to the SDL folks, and if anyones
intersted in playing, let me know - I’ll probably GPL the whole thing at
some point though.

Gordon

Hi,

I make old-fashioned 2-D video games using SDL 1.2+OpenGL®.
The games are 100% open-source / cross-platform.
Feel free to check them out here:
www.16BitSoft.com

Enjoy!

Jesse "JeZ+Lee"
16BitSoft
Video Game Design Studio
www.16BitSoft.comOn 03/15/2012 09:53 AM, Gordon Henderson wrote:

Wondering if there’s a projects page of sorts - I think it’s nice to
know what others are owrking on sometimes (top-secret game releases
not withstanding!), however…

One of the SDL projects I’ve been working on is a BASIC interpreter
(purely as a bit of nostalgia, but who knows) so it’s been quite
interesting to try to re-create the sort of environment I used in the
late 1970s-80s… (Apple II, BBC Micro, etc.)

(The other is to do with monitoring “stuff” from sensors like
temperature, pressure, and dull, boring stuff like that, however I’m
now thinking that my BASIC interpreter is actually a much nicer way to
handle and display the data than a big C program!)

SDL has been a bit of a life-saver, so a big thanks to all who work on
it. I’ve never done any graphics under a modern PC/Unix/Linux system
and the entry level to just opening a window seemed rather large until
I found SDL…

So some of the issues I’ve had is that I’ve had no control over what
the interpreter is actually executing, so no real idea when to do the
Flip/Update, other than to make some guesses - my current compromise
is to Flip when the program pauses for input (and at every character
read), and after every new line printed, and to provide a function to
explicitly do a flip/update. Issues still to be resolved is things like

PRINT "The answer is … ";
…do something that takes time
PRINT 42

with the first bit of text not being output until the newline - unless
the program explicitly calls the Flip instruction - although I did add
in the option of printing ASCII 4 (control-d) as a bit of a hack. I
found that doing an update after every single PRINT, while giving good
results really did slow it down quite a bit.

ObScreenshot:

http://unicorn.drogon.net/rtb1.png

the WAIT() call normally waits for milliseconds, but give it 0 and it
does the Flip.

I’m even toying with the same FAST/SLOW modes that the old ZX81 had -
it’s a similar sort of problem!

Although not originally on my to-do list, I want to run this on a
Raspberry Pi, so have one on order - it runs fine inside QEMU running
the Debian Pi distribution though, but the other recent posts about
cross compiling are very intersting too - to be able to procuce a Win
and Mac version without leaving the comfort of my Linux desktop is
very exciting!

Other issues I’ve faced - detecting Control-C (or Escape) to stop a
running program - calling SDL_PollEvent is slow! So I need to
investigate more efficient ways of doing that - currently calling it
once every 100 lines of BASIC have been executed. Maybe a separate
thread to set a global variable, who knows. (suggestions welcome, but
I’ve not delved into the whole timers/events/mask stuff in any detail
yet)

And bitmap fonts? Seems to be a lot, but I’m lacking the tools to
convert them - although I have the means to convert a BMP file into a
font.h array which is what I’ve used in the past. (I don’t think an
8x8 font at 640x480 out of the Composite video connector on the RPi is
going to be very visible although software doubling it would be trivial)

Anyway there you go - thanks again to the SDL folks, and if anyones
intersted in playing, let me know - I’ll probably GPL the whole thing
at some point though.

Gordon


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

try here:
http://www.libsdl.org/games.php

Also look under Demos, Applications, and Libraries under Downloads on
the left sidebar.On 15 March 2012 09:53, Gordon Henderson <gordon+sdl at drogon.net> wrote:

Wondering if there’s a projects page of sorts - I think it’s nice to know
what others are owrking on sometimes (top-secret game releases not
withstanding!), however…

Kenneth Bull wrote:> On 15 March 2012 09:53, Gordon Henderson <gordon+sdl at drogon.net> wrote:

Wondering if there’s a projects page of sorts - I think it’s nice to know
what others are owrking on sometimes (top-secret game releases not
withstanding!), however…

try here:
http://www.libsdl.org/games.php

Also look under Demos, Applications, and Libraries under Downloads on
the left sidebar.

Also when people post new demos / applications / libraries they get
announced here: http://www.libsdl.org/news.php

Message-ID: <alpine.DEB.2.00.1203151205110.10815 at unicorn.drogon.net>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

So some of the issues I’ve had is that I’ve had no control over what the
interpreter is actually executing, so no real idea when to do the
Flip/Update, other than to make some guesses - my current compromise is to
Flip when the program pauses for input (and at every character read), and
after every new line printed, and to provide a function to explicitly do a
flip/update. Issues still to be resolved is things like

PRINT "The answer is … ";
…do something that takes time
PRINT 42

with the first bit of text not being output until the newline - unless the
program explicitly calls the Flip instruction - although I did add in the
option of printing ASCII 4 (control-d) as a bit of a hack. I found that
doing an update after every single PRINT, while giving good results really
did slow it down quite a bit.

ObScreenshot:

http://unicorn.drogon.net/rtb1.png

the WAIT() call normally waits for milliseconds, but give it 0 and it does
the Flip.

I’m even toying with the same FAST/SLOW modes that the old ZX81 had - it’s
a similar sort of problem!

Having explored roughly this sort of problem (adding gui support to an
existing runtime-compiler/vm, in my case), I advise sticking all of
the ACTUAL windowing code in a separate thread (technically the
initial thread, for cross-compatibility reasons) from everything else.
Use two one-way atomic queues (singly-linked lists, in essence) for
communication purposes: one to send data to the rendering thread, &
the other to receive it back (useful for coordination & event
passing).

From a different (but not mutually exclusive) perspective, have you
considered having two print keywords, one which forces a screen
refresh (maybe PRINTU for “print & update”?) & one that doesn’t
(normal “PRINT”: it might update the screen, it might not)? You might
not know when the perfect time to refresh the screen is, but the
person writing the Basic program probably does.

Other issues I’ve faced - detecting Control-C (or Escape) to stop a
running program - calling SDL_PollEvent is slow! So I need to investigate
more efficient ways of doing that - currently calling it once every 100
lines of BASIC have been executed. Maybe a separate thread to set a global
variable, who knows. (suggestions welcome, but I’ve not delved into the
whole timers/events/mask stuff in any detail yet)

Once again, gui thread! My case was/is a little special (the vm
expects operations to happen within a roughly fixed amount of time, so
that it can ‘punish’ poorly behaving code!) but having a small timing
disconnect (that you get to custom design!) in IO can be very useful
for performance.

And bitmap fonts? Seems to be a lot, but I’m lacking the tools to convert
them - although I have the means to convert a BMP file into a font.h array
which is what I’ve used in the past. (I don’t think an 8x8 font at 640x480
out of the Composite video connector on the RPi is going to be very
visible although software doubling it would be trivial)

Why bitmap? If you write a small shapes library (lines & circular arcs
would easily handle most of English: you’d just need to figure out
dots for periods, semi-colons, etc.) then you can apply scaling on the
same font and get any size of letters that you want. If a width could
be specified, then you could do bold letters with the same font. If a
per-row offset could be specified, you could do italics with the same
font. A “1” is, for example, two lines. A “2” is two lines and a
circular arc. Since you already have the foundational gui elements
working, you can design the individual characters inside of your
interpreter.> Date: Thu, 15 Mar 2012 13:53:08 +0000 (GMT)

From: Gordon Henderson <gordon+sdl at drogon.net>
To: sdl at lists.libsdl.org
Subject: [SDL] In-case anyone is interested…

Message-ID: <alpine.DEB.2.00.1203151205110.10815 at unicorn.drogon.net>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

So some of the issues I’ve had is that I’ve had no control over what the
interpreter is actually executing, so no real idea when to do the
Flip/Update, other than to make some guesses - my current compromise is to
Flip when the program pauses for input (and at every character read), and
after every new line printed, and to provide a function to explicitly do a
flip/update. Issues still to be resolved is things like

PRINT "The answer is … ";
…do something that takes time
PRINT 42

with the first bit of text not being output until the newline - unless the
program explicitly calls the Flip instruction - although I did add in the
option of printing ASCII 4 (control-d) as a bit of a hack. I found that
doing an update after every single PRINT, while giving good results really
did slow it down quite a bit.

ObScreenshot:

http://unicorn.drogon.net/rtb1.png

the WAIT() call normally waits for milliseconds, but give it 0 and it does
the Flip.

I’m even toying with the same FAST/SLOW modes that the old ZX81 had - it’s
a similar sort of problem!

Having explored roughly this sort of problem (adding gui support to an
existing runtime-compiler/vm, in my case), I advise sticking all of
the ACTUAL windowing code in a separate thread (technically the
initial thread, for cross-compatibility reasons) from everything else.
Use two one-way atomic queues (singly-linked lists, in essence) for
communication purposes: one to send data to the rendering thread, &
the other to receive it back (useful for coordination & event
passing).

From a different (but not mutually exclusive) perspective, have you
considered having two print keywords, one which forces a screen
refresh (maybe PRINTU for “print & update”?) & one that doesn’t
(normal “PRINT”: it might update the screen, it might not)? You might
not know when the perfect time to refresh the screen is, but the
person writing the Basic program probably does.

this is my plan for now - well, similar to it - user can force an update
by executing WAIT(0), or by printing chr$(4)…

Other issues I’ve faced - detecting Control-C (or Escape) to stop a
running program - calling SDL_PollEvent is slow! So I need to investigate
more efficient ways of doing that - currently calling it once every 100
lines of BASIC have been executed. Maybe a separate thread to set a global
variable, who knows. (suggestions welcome, but I’ve not delved into the
whole timers/events/mask stuff in any detail yet)

Once again, gui thread! My case was/is a little special (the vm
expects operations to happen within a roughly fixed amount of time, so
that it can ‘punish’ poorly behaving code!) but having a small timing
disconnect (that you get to custom design!) in IO can be very useful
for performance.

Threads - Yes. And actually, since I’ve done a lot of concurrent/parallel
programming, and writing things like interrupt driven serial port
handlers, it’s actually easy (so why didn’t I think of it earlier!)
Although I’ve never done any multi threaded stuff in Linux, but it looks
like I can more or less emulate an interrupt driven keyboard handler,
stuffing characters into an input buffer for the main program to take them
out of (seting a global “control-c” type flag in the process) with a few
simple calls to SDL_Createthread and a mutex… May my philosophers never
go hungry…

And bitmap fonts? Seems to be a lot, but I’m lacking the tools to convert
them - although I have the means to convert a BMP file into a font.h array
which is what I’ve used in the past. (I don’t think an 8x8 font at 640x480
out of the Composite video connector on the RPi is going to be very
visible although software doubling it would be trivial)

Why bitmap?

Because it’s easy and I’m lazy… And because I want that true 80’s
experience :slight_smile:

Got some other pointers now too.

Thanks again. Had some good replies on & off list.

Cheers,

GordonOn Thu, 15 Mar 2012, Jared Maddox wrote:

Date: Thu, 15 Mar 2012 13:53:08 +0000 (GMT)
From: Gordon Henderson <gordon+sdl at drogon.net>
To: sdl at lists.libsdl.org
Subject: [SDL] In-case anyone is interested…