How about low-brow?

[Unseen Machine]

I get ya but to me, an please dont take my preference or style as a "Heres how ya do it", once you take that base code (the subs, udts etc...) and then make them as a .bm, your future coding only needs to link to the library. So all you end up with is the main function, i.e your code looks like this

Code: (Select All)

'/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

'/////////////////////////////////////////////    Low Brow Libs    ///////////////////////////////////////////////////

'/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////



DIM SHARED Sys_State AS System_State '// This contains our basic program data, screen handle, input and timers



Main '// Call the program



'/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////



SUB Main

  '// First we set up using the system_state_new function. This creates our screen, initialises the input data and timers

  System_State_New Sys_State, 0, 0, 800, 600, "Low Brow Dev"



  DO

    _LIMIT 144 '// 144 fps is the modern default as most modern screens have this refresh rate

    '// Logic first

    System_State_Update Sys_State '// Update the system data (timers and input) - later we can add screen resizing etc...



    '// Graphics

    CLS '// Clear the screen



    PRINT "Mouse info"

    PRINT

    PRINT "X : " + STR$(Sys_State.Mouse.Position.X)

    PRINT "Y : " + STR$(Sys_State.Mouse.Position.Y)

    PRINT

    PRINT "LB : " + STR$(Sys_State.Mouse.LB)

    PRINT "RB : " + STR$(Sys_State.Mouse.RB)

    PRINT "MB : " + STR$(Sys_State.Mouse.MB)

    PRINT "MW : " + STR$(Sys_State.Mouse.MW)





    _DISPLAY '// Update the display



  LOOP UNTIL _EXIT '// Loop until the eXit button is pressed



  '// Here you would free any memory youve allocated to avoid memory leaks



  SYSTEM '// End the program



END SUB





'/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////



REM $INCLUDE:'LBrow.bm'



'/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Whilst this obscures the underlying functions it allows a user, in two commands to create and update the system state. I can be sure that 90% of the code you make uses a SCREEN command, requires input handlers *you can add kb and gpads to this in the same method as ive shown with the mouse...and further expansion of the underlying UDT's and a couple more params or separate functions will allow the user to write something ONCE and then use it as needed...If this method sits well with you, the same vector and rect basic UDT's can be used for games (Collision detection, animated sprites), GUI's and more without EVER needing to re-write something that is fundamental.

I'm always a BIG FAN of making code accessible and simple (as i know you've inferenced this from my Titan GDK) and teaching is to me the ultimate use of my knowledge so if in anyway i can help YOU create a series of tutorials that fit your ideas then I (and pretty much everyone else who isnt an elitist here) am/are happy to help...we can only give you OUR ideas, we dont all agree, we all code differently so as YOU posed the question it'll be down to YOU to filter through it all and create the "QB64 PE Tutorials for Newbs" that as you say, will help draw in and educate said Newbs!

Next one from me will be using vectors along with a speed and rotation to move objects, SAT for collision detection and then i'll wait until YOU tell us how WE *The old guard? Should proceed...

Glad you liked it though, and think, your booglish with MasterGy's dice code converted to have the letters and not numbers inside a cube would result in a full on 3d representation of the real world thing! (Long road ahead but its entirely possible!)

John