ScriptBasic SDL extension module

[John]

I was able to get the ScriptBasic SDL_Draw extension module working and here is the example I converted to ScriptBasic. I hope to have the SDL extension module ready for the ScriptBasic 2.2 release.

Code: [Select]

' ScriptBasic SDL_Draw Example

DECLARE SUB Window ALIAS "SB_Window" LIB "sdl"
DECLARE SUB RGB ALIAS "SB_RGB" LIB "sdl"
DECLARE SUB WaitKey ALIAS "SB_WaitKey" LIB "sdl"
DECLARE SUB Ticks ALIAS "SB_Ticks" LIB "sdl"
DECLARE SUB UpdateRect ALIAS "SB_UpdateRect" LIB "sdl"
DECLARE SUB CLS ALIAS "SB_CLS" LIB "sdl"
DECLARE SUB Draw_Pixel ALIAS "SB_Draw_Pixel" LIB "sdl"
DECLARE SUB Draw_Line ALIAS "SB_Draw_Line" LIB "sdl"
DECLARE SUB Draw_Circle ALIAS "SB_Draw_Circle" LIB "sdl"
DECLARE SUB Draw_FillCircle ALIAS "SB_Draw_FillCircle" LIB "sdl"
DECLARE SUB Draw_HLine ALIAS "SB_Draw_HLine" LIB "sdl"
DECLARE SUB Draw_VLine ALIAS "SB_Draw_VLine" LIB "sdl"
DECLARE SUB Draw_Rect ALIAS "SB_Draw_Rect" LIB "sdl"
DECLARE SUB Draw_FillRect ALIAS "SB_Draw_FillRect" LIB "sdl"
DECLARE SUB Draw_Ellipse ALIAS "SB_Draw_Ellipse" LIB "sdl"
DECLARE SUB Draw_FillEllipse ALIAS "SB_Draw_FillEllipse" LIB "sdl"
DECLARE SUB Draw_Round ALIAS "SB_Draw_Round" LIB "sdl"
DECLARE SUB Draw_FillRound ALIAS "SB_Draw_FillRound" LIB "sdl"

Window(640, 480, "ScriptBasic SDL_Draw Example")
c_white = RGB(255, 255, 255)
c_gray = RGB(200, 200, 200)
c_dgray = RGB(64, 64, 64)
c_cyan = RGB(32, 255, 255)
Draw_Line(100, 100, 30, 0, c_white)
Draw_Line(30, 0, 100, 100, c_white)
Draw_Line(100, 100, 30, 0, c_white)
Draw_Line(30, 0, 100, 100, c_white)
Draw_Line(0, 0, 100, 100, c_white)
Draw_Line(100, 100, 300, 200, c_white)
Draw_Line(200, 300, 250, 400, RGB(128, 128, 255))
Draw_Line(500, 50, 600, 70, RGB(128, 255, 128))
Draw_Line(500, 50, 600, 70, RGB(128, 255, 128))
Draw_Circle(100, 100, 50, c_white)
Draw_Circle(150, 150, 5, c_white)
Draw_Circle(150, 150, 4, RGB(64, 64, 64))
Draw_Circle(150, 150, 3, RGB(255, 0, 0))
Draw_Circle(150, 150, 2, RGB(0, 255, 0))
Draw_Circle(150, 150, 1, RGB(0, 0, 255))
Draw_Line(500, 100, 600, 120, RGB(128, 255, 128))
Draw_Circle(601, 121, 2, c_white)
Draw_Circle(400, 200, 2, c_white)
Draw_Line(400, 200, 409, 200, c_white)
Draw_Circle(409, 200, 2, c_white)
Draw_Line(400, 200, 400, 250, c_white)
Draw_Circle(400, 250, 2, c_white)
Draw_Line(409, 200, 400, 250, c_white)
Draw_Line(400, 300, 409, 300, c_gray)
Draw_Line(400, 300, 400, 350, c_gray)
Draw_Line(409,300, 400, 350, c_dgray)
Draw_Rect(398, 298, 4, 4, c_cyan)
Draw_Rect(407, 298, 4, 4, c_cyan)
Draw_Rect(398, 348, 4, 4, c_cyan)
Draw_HLine(10, 400, 50, c_white)
Draw_VLine(60, 400, 360, c_white)
Draw_Rect(500, 400, 50, 50, c_white)
Draw_Pixel(510, 410, c_white)
Draw_Pixel(520, 420, RGB(255, 0, 0))
Draw_Pixel(530, 430, RGB(0, 255, 0))
Draw_Pixel(540,440, RGB(0, 0, 255))
Draw_Ellipse(100, 300, 60, 30, c_white)
Draw_FillEllipse(300, 300, 30, 60, RGB(64, 64, 200))
Draw_Ellipse(300, 300, 30, 60, RGB(255, 0, 0))
Draw_Round(200, 20, 70, 50, 10, c_white)
Draw_Round(300, 20, 70, 50, 20, RGB(255, 0, 0))
Draw_FillRound(390, 20, 70, 50, 20, RGB(255, 0, 0))
Draw_Round(390, 20, 70, 50, 20, c_cyan)
Draw_Rect(499, 199, 52, 72, RGB(255, 255, 0))
Draw_FillRect(500, 200, 50, 70, RGB(64, 200, 64))
Draw_FillCircle(500, 330, 30, c_cyan)
 
UpdateRect

WaitKey


Code: [Select]

' ScriptBasic Peacock

DECLARE SUB Window ALIAS "SB_Window" LIB "sdl"
DECLARE SUB WaitKey ALIAS "SB_WaitKey" LIB "sdl"
DECLARE SUB Ticks ALIAS "SB_Ticks" LIB "sdl"
DECLARE SUB UpdateRect ALIAS "SB_UpdateRect" LIB "sdl"
DECLARE SUB Draw_Line ALIAS "SB_Draw_Line" LIB "sdl"

Window 700, 500, "Peacock Plume"
q = 1
q1 = 0.9997
v = 0.01
vv = 0.0004
xs = 750
ys = 730
xm = 650
ym = 180
br = -0.7393
bi = 0.117
ar = 0.0
ai = 0.0
_cos = cos(0.01)
_sin = sin(0.01)
t1 = Ticks()
FOR d = 1 TO 15000
  tr = ar * ar - ai * ai + br
  ti = 2 * ar * ai + bi
  x  = tr * xs + xm
  y  = ti * ys + ym
  v  = v + vv
  q  = q * q1
  c  = d ^ 2.1
  Draw_Line x, y, x + (_cos * 50 * q), y + (_sin * 50 * q), c
  ar = tr
  ai = ti
NEXT
UpdateRect
t2 = Ticks()
t3 = (t2 - t1) / 1000
PRINT "Time:  ", FORMAT("%.4f", t3), " seconds.\n"
PRINT d-1, " Lines Drawn\n"
WaitKey

jrs@laptop:~/sb/sb22/sdl$ scriba peacock.sb
Time:  0.0880 seconds.
15000 Lines Drawn
jrs@laptop:~/sb/sb22/sdl$

Code: [Select]

' ScriptBasic Circle

DECLARE SUB Window ALIAS "SB_Window" LIB "sdl"
DECLARE SUB WaitKey ALIAS "SB_WaitKey" LIB "sdl"
DECLARE SUB UpdateRect ALIAS "SB_UpdateRect" LIB "sdl"
DECLARE SUB RGB ALIAS "SB_RGB" LIB "sdl"
DECLARE SUB CLS ALIAS "SB_CLS" LIB "sdl"
DECLARE SUB Draw_Circle ALIAS "SB_Draw_Circle" LIB "sdl"

Window 800, 600, "ScriptBasic Circle"
w = 400
h = 300
CLS(RGB(255, 255, 255))
black = RGB(0, 0, 0)
FOR i = 0 TO 130 STEP 10
  Draw_Circle w - i, h + i, i, black
  Draw_Circle w + i, h - i, i, black
  Draw_Circle w + i, h + i, i, black
  Draw_Circle w - i, h - i, i, black
NEXT
UpdateRect
WaitKey


[John]

In my quest for a SDL UI for ScriptBasic that will run on Android, I began working on the console part of the project. Here are a couple examples that come with the SDL terminal library I will be using.

<a href="http://files.allbasic.info/ScriptBasic/SDL/termcube.swf" target="_blank" rel="noopener noreferrer" class="bbc_link bbc_flash_disabled new_win">http://files.allbasic.info/ScriptBasic/SDL/termcube.swf</a>

[John]

If anyone is interesting in what game development might be like using SDL, here is an example.




This is a list of the platforms SDL supports, and who maintains them.

Officially supported platforms
 ==============================
(code compiles, and thoroughly tested for release)
==============================
Windows XP/Vista/7/8
Mac OS X 10.5+
Linux 2.6+
iOS 5.1.1+
Android 2.3.3+

Unofficially supported platforms
================================
(code compiles, but not thoroughly tested)
================================
FreeBSD
NetBSD
OpenBSD
Solaris

Platforms supported by volunteers
=================================
Haiku - maintained by Axel Dörfler
PSP - maintained by <unknown>
Pandora - maintained by Scott Smith

[Mike Lobanovsky]

The box movie does look impressive.

Do you plan to confine yourself to pure BASIC graphics as far as a standard SB distro goes or are you going to re-implement all there is in SDL in your own distro, probably in some form of an add-on module (don't know yet what equivalent to a dynamic-link library there is on Android)?

[John]

Scriba is a console interpreter with no built in graphics abilities. Scriba and any extension modules components will need to be static linked. Your native C coded is called from the JavaVM via JNI. This is the reason I haven't released the Wetspot II game I ported to Android. I need to embed the resources to the game as a binary string and unpack them to 'disk' on install. PITA to say the least. I'm hoping the C4droid author comes up with a better solution.

 Here is a minimalistic terminal example using the Peacock Plume code.

Code: [Select]

' ScriptBasic Peacock

DECLARE SUB Window ALIAS "SB_Window" LIB "sdl"
DECLARE SUB WaitKey ALIAS "SB_WaitKey" LIB "sdl"
DECLARE SUB Ticks ALIAS "SB_Ticks" LIB "sdl"
DECLARE SUB UpdateRect ALIAS "SB_UpdateRect" LIB "sdl"
DECLARE SUB Draw_Line ALIAS "SB_Draw_Line" LIB "sdl"
DECLARE SUB CreateTerm ALIAS "SB_CreateTerminal" LIB "sdl"
DECLARE SUB TermSize ALIAS "SB_TerminalSetSize" LIB "sdl"
DECLARE SUB TermPrint ALIAS "SB_TerminalPrint" LIB "sdl"
DECLARE SUB TermShow ALIAS "SB_TerminalBlit" LIB "sdl"
DECLARE SUB TermPosition ALIAS "SB_TerminalSetPosition" LIB "sdl"
DECLARE SUB TermFont ALIAS "SB_TerminalSetFont" LIB "sdl"
DECLARE SUB TermSetColor ALIAS "SB_TerminalSetColor" LIB "sdl"
DECLARE SUB TermBorderColor ALIAS "SB_TerminalSetBorderColor" LIB "sdl"
DECLARE SUB FGColor ALIAS "SB_TerminalSetForeground" LIB "sdl"
DECLARE SUB BGColor ALIAS "SB_TerminalSetBackground" LIB "sdl"
DECLARE SUB TermClear ALIAS "SB_TerminalClear" LIB "sdl"

Window 700, 500, "Peacock Plume"
q = 1
q1 = 0.9997
v = 0.01
vv = 0.0004
xs = 750
ys = 730
xm = 650
ym = 180
br = -0.7393
bi = 0.117
ar = 0.0
ai = 0.0
_cos = cos(0.01)
_sin = sin(0.01)
t1 = Ticks()
FOR d = 1 TO 15000
  tr = ar * ar - ai * ai + br
  ti = 2 * ar * ai + bi
  x  = tr * xs + xm
  y  = ti * ys + ym
  v  = v + vv
  q  = q * q1
  c  = d ^ 2.1
  Draw_Line x, y, x + (_cos * 50 * q), y + (_sin * 50 * q), c
  ar = tr
  ai = ti
NEXT
t2 = Ticks()
t3 = (t2 - t1) / 1000
CreateTerm
TermFont "./VeraMono.ttf", 12
TermSize 40, 2
TermPosition 10, 450
TermSetColor 0, 0, 0, 0
TermBorderColor 0, 0, 0, 0
FGColor 255,255,255,255
BGColor 0,0,0,0
TermClear
TermPrint FORMAT("%.4f", t3) & " Seconds\n"
TermPrint STR(d-1) & " Lines Drawn"
TermShow
UpdateRect
WaitKey


[Mike Lobanovsky]

Scriba is a console interpreter with no built in graphics abilities.

That I understand. But I also understand pretty clear that a BASIC without graphics will remain a BASIC of the yesteryear even if it is 128- or 1024-bit capable. Modern consumer platforms are all graphical and even Linux is moving admittedly in this direction though not very consistently.

Graphics may be explored in two major ways. One way is to use 3rd-party API's in an SB+SDL or FBSL+User32+Gdi32+GdiPlus manner. The other way is to develop an own graphics module (standalone or built-in) with high-level features that would combine several API calls in one to avoid code complexity and also reduce  the interpreted call overhead. I prefer the former low-level approach but FBSL has also a few high-level graphics facilities like Line(), Circle(), Arc(), Fill(), Text(), etc. for simpler tasks that help newcomers move over from VB and compatibles with lesser headaches.

So my question was if you're planning to add such high-level features to SB or stay with SDL API's that are eating so much space in the script just to declare their entry points without argument quantity and type checking?

I'm hinting at FBSL that has over 2,300 API's always preloaded on app start and that needs only 1 short line of code to load thousands more.

[John]

The SDL extension module DECLARE and API constants will live in a separate include file and IMPORTed (only add once) at the top of the script. I don't know how far I'm going to go with this. If it continues to be this easy, we may end up with a nice SDL interface for SB that is cross platform. The nice part is I really don't have to write any new code and only interface to it.

Code: [Select]

' ScriptBasic Peacock

IMPORT sdl.inc

Window 700, 500, "Peacock Plume"
q = 1
q1 = 0.9997
v = 0.01
vv = 0.0004
xs = 750
ys = 730
xm = 650
ym = 180
br = -0.7393
bi = 0.117
ar = 0.0
ai = 0.0
_cos = cos(0.01)
_sin = sin(0.01)
t1 = Ticks()
FOR d = 1 TO 15000
  tr = ar * ar - ai * ai + br
  ti = 2 * ar * ai + bi
  x  = tr * xs + xm
  y  = ti * ys + ym
  v  = v + vv
  q  = q * q1
  c  = d ^ 2.1
  Draw_Line x, y, x + (_cos * 50 * q), y + (_sin * 50 * q), c
  ar = tr
  ai = ti
NEXT
t2 = Ticks()
t3 = (t2 - t1) / 1000
CreateTerm
TermFont "./VeraMono.ttf", 12
TermSize 40, 2
TermPosition 10, 450
TermSetColor 0, 0, 0, 0
TermBorderColor 0, 0, 0, 0
FGColor 255,255,255,255
BGColor 0,0,0,0
TermClear
TermPrint FORMAT("%.4f", t3) & " Seconds\n"
TermPrint STR(d-1) & " Lines Drawn"
TermShow
UpdateRect
WaitKey


[Mike Lobanovsky]

Oh yes, I know only too well that annoying feeling when you download somebody else's project and then run all over the net in a vain attempt to find the key include missing in the download. I'm mostly a C programmer, you know.

How does Scriba communicate with standalone libraries of a platform, say, Linux and/or Mac? Are there any on Android at all?

[John]

When I create a SB C extension module (shared object - dll, so, ...) it's unique to SB as there is a bit of handshaking that goes on with the load/unload  and basically SB is passing a pointer to it's object model. SB is very object oriented and a pointer nightmare without the #defines and macros that makes it a breeze to use. It's daunting at first but once you get it, you'll never turn back. I wouldn't have invested 8 years into SB if I thought it was a POS.

FYI: The Makefile for the extension module creates both a dynamic (.dll/.so) and a static C library. (.obj/.a) If I chose to compile my script to C, I can either use the dynamic libraries (what scriba uses) or static link them. (reason to compile to C)

[John]

I think the Aries Engine is more than I'm willing to take on with the ScriptBasic SDL extension module. I'm not a gamer and have little interest in that area of programming. I will probably add simple sprites and text functions to the extension module and make it part of the ScriptBasic 2.2 release.

Have a Merry Christmas!

[John]

I added SDL_image to the ScriptBasic SDL extension module.

Code: [Select]

' ScriptBasic SDL Image

DECLARE SUB Window ALIAS "SB_Window" LIB "sdl"
DECLARE SUB WaitKey ALIAS "SB_WaitKey" LIB "sdl"
DECLARE SUB LoadImage ALIAS "SB_LoadImage" LIB "sdl"
DECLARE SUB ShowImage ALIAS "SB_ShowImage" LIB "sdl"


Window 400, 300, "ScriptBasic SDL Image"
img = LoadImage("sblogo.gif")
ShowImage img, 100, 75
WaitKey


[John]

Here is a brute force method of moving an image using the current SB SDL extension module API. I'm trying to keep the SB SDL API simple to use and moving images in SDL (without layers) isn't pretty. My thought is return a pointer to a RECT that contains the current background at the position you plan to place your image. When you want to move an image you would restore the save background at the current image position.  The ShowImage function would be used to show both the saved background and the image. (which may be located at another position on the screen)

   

Code: [Select]

' ScriptBasic SDL Image

DECLARE SUB Window ALIAS "SB_Window" LIB "sdl"
DECLARE SUB CLS ALIAS "SB_CLS" LIB "sdl"
DECLARE SUB RGB ALIAS "SB_RGB" LIB "sdl"
DECLARE SUB WaitKey ALIAS "SB_WaitKey" LIB "sdl"
DECLARE SUB LoadImage ALIAS "SB_LoadImage" LIB "sdl"
DECLARE SUB ShowImage ALIAS "SB_ShowImage" LIB "sdl"

Window 400, 300, "ScriptBasic SDL Image"
img = LoadImage("sblogo.gif")
ShowImage img, 100, 75
SLEEP(1)
CLS(RGB(0,0,0))
ShowImage img, 1, 1
WaitKey

Update: I decided to go with an image list that maintains the pointers to the image and the background that was there prior to placing the image. I will have a ClearImage function that will restore the background as it was and a DeleteImage to release the memory for the image and remove it from the image list. As part of the unload / shutdown of the extension module it will cycle through the loaded image list and delete them from memory and finally release the memory use for the graphics surface.

[Mike Lobanovsky]

This looks like a special case solution for just one opaque image and static (unchanging) background. Should the background go dynamic and/or more than one potentially alpha-transparent image loaded/moved/overlapped, the problem will immediately swell out to having to design an own image windowing system with all the relevant z-sorting, compositing, and memory management sub-problems in your lap.

What SDL graphics does natively, it does hardware-assisted where possible. Your alternatives are likely to be significantly slower and prone to memory leaks. I'd use SDL native facilities for such intricate stuff as generic image management.

[John]

The ShowImage function would make a background backup of whatever is current there. Once you blit an image / draw function to the SDL surface, it's one entity. It's up to the programmer to save backgrounds and destroy the memory used by these operations. I agree that I should make the background backup an optional feature. For example if I were using an image to paint the background on the initially black surface, I wouldn't need to make a backup. (background pointer in the image list would be null)

The goal of high level languages like ScriptBasic is to only expose as much as you need to get the job done. There are trade offs (speed, simple SDL functionality, ...) but SB isn't trying to be anything else. One is free to extend the extension module and add whatever features they like. (easy to do, written is SB/C BASIC format)

[Mike Lobanovsky]

Wow-wow-wow John,

Your message elaborates on "a brute force method of moving an image" around the window background. So I repeat, your background rect storage solution has sense only if the background remains positionally static and visually unchanged at all times and a loaded image is the only image in the scene. As soon as a second overlapping image appears and/or background starts to scroll or change its pattern dynamically, the respective rects stored previously become invalid and inapplicable. They will only waste system resources and add to the overall memory fragmentation for no practical purpose whatsoever.

Avoiding this efficiently is what compositing backgrounds and images into a backbuffer is all about; it isn't a task for just a simple BASIC function, however "high level" it is. It will most likely grow into a separate library that had better be harware-assisted. So contrary to what you're saying, your "high level" SB solution will not get a generic job done. I would personally leave image handling alone in an indie language. It is always intricate low-level stuff and there aren't so many image libraries around that can cope with it decently.