Graphics for Lisp & Basic

[Charles Pegge]

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.

[Mike Lobanovsky]

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?

[Charles Pegge]

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.

[Charles Pegge]

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

[Mike Lobanovsky]

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...)

[Charles Pegge]

Ah, but does that figure include large headers?

Dumping unused equates in the early stages of compiling.

[Mike Lobanovsky]

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.

[Charles Pegge]

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

Code: [Select]

  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

Code: [Select]

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: --->


.

[JRS]

Code: [Select]

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

 

[Mike Lobanovsky]

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.

[JRS]

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.

[Charles Pegge]

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



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.

[JRS]

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!

[Charles Pegge]

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</>
</>

[Mike Lobanovsky]

... 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.