Oxygen Basic
Information => Open Forum => Topic started by: Charles Pegge on October 01, 2014, 07:21:22 AM
-
This topic has branched from Lisp in Basic
Hi Mike,
Making a graphics DLL has some advantages over an include-source-code version.
Primarily, it is accessible to a variety of external Schemes and Lisps, and anything else that can read and write char* with a DLL function.
Also avoids encapsulation issues when encoding the Windows GUI with Opengl, and multithreading. There are many state variables that would need to be hidden.
And the compile-time for JIT scripts would be unacceptably slow, if it had to build the entire binary from scratch every time.
-
Hi Charles,
Primarily, it is accessible to a variety of external Schemes and Lisps, and anything else that can read and write char* with a DLL function. Also avoids encapsulation issues when encoding the Windows GUI with Opengl, and multithreading. There are many state variables that would need to be hidden.
Then I think we should be talking about a general-purpose GUI+graphics module for Oxygen without particular referral to the hateful Lisp or Scheme. Something of an own IUP or wxWidgets or Qt. What would your estimation be of the viability of such a library in which its constituent parts communicate with each other by way of string interchange rather than numeric stack and direct access to common memory?
And the compile-time for JIT scripts would be unacceptably slow, if it had to build the entire binary from scratch every time.
Are things really that bad with OxygenBasic's JIT compiler throughput?
-
Re: Leadership & Dictators
The web has made billions of people aware of the appalling consequences of warfare, and has begun to expose how many of these gruesome conflicts have been orchestrated by staging false-flag provocation events, and by the funding and logistics from the few who would profit.
I hope this will mark the end of blind obedience to authority.
-
Hi Mike,
The string interface is indeed a narrow orifice, but it is a simple one to start with, and probably the most suitable for Lisp. I hope to produce a conceptual piece very soon.
Oxygen's compiling speed is not bad, but a substantial GUI would add 3-4 seconds compile time to a script which would otherwise fire up in a fraction of a second.
I run all my tools from source, except for the compiler :)
-
Oxygen's compiling speed is not bad, but a substantial GUI would add 3-4 seconds compile time to a script which would otherwise fire up in a fraction of a second.
Hmmm, I didn't realize that until now that you've pointed it out. (FBSL's DynC compiles up to 50MB of C source code per second on my PC...)
-
Ah, but does that figure include large headers? :)
Dumping unused equates in the early stages of compiling.
-
Charles,
DynC utilizes standard gcc headers but it can get by perfectly without any of them. Everything simply falls back to ints and void pointers transparently, and you just add a handful of #defines and typedefs that are actually needed in your code. If the library functions you're using return something that can't be reduced to a simple integer (e.g. byval doubles or long longs) or if they aren't of CDECL type, then you're supposed to add their protos too. Naturally enough, user-defined functions don't need prototyping if their code precedes their deployment.
On my PC, the 44-file 100K-line XANEngine project written in BASIC + C + Asm launches for execution in less than 200 milliseconds including the time to load its configuration files. Fbsl.exe's own startup time is around 30 milliseconds including in-memory decompression (7-zip compatible LZMA) and initialization of some 200KB+ of its internal tables of string and byte data embedded in the executable proper.
-
Thanks Mike.
Here is the seed of the graphics dll interface.
The window normally runs in its own thread, and does not block communications with the client.
O2 DLL side
function run(optional p) callback
=================================
MainWindow width,height,WS_OVERLAPPEDWINDOW
end function
extern export
function grun(optional m)
===============================
static sys th,da,id
select m
case 0 : run 'not in thread
case 1 : th=CreateThread1 null,0,@run,@da,0,0
case else : WaitForMultipleObjects 1,@th,1,-1
CloseHandle th
end select
end function
function iotxt(char*pc) as sys 'as char* in API header
==============================
sys a
sys i=1
string s=pc
static string w,v,r
w=getword s,i
'
'INTERPRET COMMAND
if w="title"
a=i+1
endline s,i
title=mid s,a,i-a
r=title
end if
actn++ 'refresh screen
'
'RETURN DATA
return strptr r
end function
end extern
O2 Client side
extern lib "t.dll"
! grun (mode)
! iotxt (char*pr) as char*
end extern
grun 1 'start thread
mbox iotxt "title 2D Graphics"
mbox iotxt "title 2D & 3D Graphics" 'change title
...
grun -1 'close thread
Graphics borrowed from projectsA/OpenglCns: --->
.
-
mbox iotxt "title 2D Graphics"
Charles,
May I suggest using a "title=..." or "title:..." or make "title" a separate argument. It doesn't seem intuitive the way you have it now. IMHO
-
Charles,
Before John and I go to sleep on the opposite sides of the globe, hehe, may I suggest that we use something like precalculated "magic" crc32 hashes (sort of byte codes) rather than verbatim string commands? Graphics is too speed sensitive to let strings get in its way.
-
may I suggest that we use something like precalculated "magic" crc32 hashes (sort of byte codes) rather than verbatim string commands?
Is this question of compiling speed or final executable speed? I thought O2 ends up as ASM.
-
Hi John,
I am leaning towards Lisp notation, especially for graphical objects which may require several attributes.
For instance:
( object myBox
(scale 4 2 1)
(shape cube)
(material metallic)
(color green)
)
( object myboxA
(mybox)
(rotX 45)
(id 24)
)
(show
( pos 0.5, 0.2, 0.0 )
(myboxA)
)
Hi Mike,
You are a night bird, like the owl in my garden :)
(http://thefeaturedcreature.thefeaturedcreat.netdna-cdn.com/wp-content/uploads/2013/02/eyes-great-horned-owl-intense.jpg)
Yes, I think hash codes will be useful for dynamic low level coding. But we can offer, for the most part, high level graphics, and make use of OpenGl's compiled lists to render graphical objects efficiently.
-
I am leaning towards Lisp notation, especially for graphical objects which may require several attributes.
I missed the implied Lisp notation in the O2 code. I understand where you are going now. Thanks!
Maybe I need a set of eyes like your owl friend. Great shot.
An Owl's eyes are large in order to improve their efficiency, especially under low light conditions. In fact, the eyes are so well developed, that they are not eye balls as such, but elongated tubes. They are held in place by bony structures in the skull called Sclerotic rings. For this reason, an Owl cannot ::) or move its eyes - that is, it can only look straight ahead!
-
That was a borrowed webshot, as always. But I hear him in the early hours. It must be the mating season. There are also foxes and badgers around, and innumerable cats. So you would not get a good night's sleep camping out.
With regard to notation, other styles could be used with very little syntax remapping.
Lispish
( object myboxA
(mybox)
(rotX 45)
(id 24)
)
operator:first
object (myboxA
mybox()
rotX(45)
id(24)
)
object { myboxA
mybox{}
rotX{45}
id{24}
}
markup:
<object>myboxA
<mybox></>
<rotX>45</>
<id>24</>
</>
-
... the owl in my garden :)
It must be a she-owl, it looks so dear! :)
BTW "owl" is feminine in Russian, and there is no matching word to denote a male bird of this kind. An owl is usually a wizard in our fairy tails.