Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

gone CScript

Sign in to follow this  
Norman Barrows


Well, i've done it.

I've gone CScript.

After having a C++ macro processing language at my disposal for about 15 years now, i've finanlly made the big move and fully integrated CScipt into my code development workflow. now if there was just a way to add a solution specific external tool button to the standard menu bar in VC 2012 express.....

See this journal entry from Project Z for more info on CScript....


So far, i couldn't be happier. With translation times on the order of 100,000 lines per second, the CScript macro processor stage of the new build pipeline is just a blink of an eye!.

and now i can write new code as well as modifiy existing code using CScript syntax, which is quick and easy.

Here's an example of some of the new new CScript code i'm writing now. This is an implementation of a GUI button system i added to the Z library. Granted, its only a statically allocated array with a hard coded size. but it can easily be converted to a class that gets passed a size on creation. an app will generally know how many buttons they need in a given list of buttons. in cases where they don't, a vector would do nicely in place of an array. I created it with updating the UI of the rigid body modeler/animator in mind. the modeler/animator is a linkable module with just two screens of maybe 20 hotspots each. so a single list of 100 buttons was fine for a start. in the long run, this api would evolve to have the ability to load land save lists of buttons, and store an array of button lists (or perhaps a tree for a menu hierarchy). one might even implement a callback driven event handler for it.

this CScript code is a full implementation of a buttonlist data structure with init, new, release, get, set, draw, and pick functions:

' ####################### buttons list ##############################

#d Zmaxbtns 100

st Zbtnrec
i x y w h texID active
s text

Zbtnrec Zbtn[Zmaxbtns];

fn v Zinit_btns
c ZeroMemory &Zbtn sizeof(Zbtnrec)*Zmaxbtns

fn i Znewbtn
i a
4 a Zmaxbtns
== Zbtn[a].active 0
ret a
ret -1

fn v Zreleasebtn i a
= Zbtn[a].active 0

fn v Zsetbtn i index i x i y i w i h i texID c *text
= Zbtn[index].x x
= Zbtn[index].y y
= Zbtn[index].w w
= Zbtn[index].h h
= Zbtn[index].texID texID
ss Zbtn[index].text text

fn v Zgetbtn i index i *x i *y i *w i *h i *texID c *text
= *x Zbtn[index].x
= *y Zbtn[index].y
= *w Zbtn[index].w
= *h Zbtn[index].h
= *texID Zbtn[index].texID
ss text Zbtn[index].text

fn v Zdrawbtn i index
!= Zbtn[index].texID -1
c Zdrawsprite Zbtn[index].texID Zbtn[index].x Zbtn[index].y (float)Zbtn[index].w/256.0f (float)Zbtn[index].h/256.0f
!= strcmp(Zbtn[index].text,"") 0
c Ztext Zbtn[index].x+10 Zbtn[index].y+10 Zbtn[index].text

fn i Zisinbtn i x i y i index
i a
cr a isin x y Zbtn[index].x Zbtn[index].y Zbtn[index].x+Zbtn[index].w Zbtn[index].y+Zbtn[index].h
ret a
Sign in to follow this  

1 Comment

Recommended Comments

exercise for the reader:


follow the link, and use the CScript language description to translate this into a C++ class definition that takes a button list size as a creation parameter, and uses an array as its in internal data structure.  I'm thinking the object would have a btnrec pointer and malloc and free in the constructor and destructor. I know! why not use vector?

because both type and size of the array are known ahead of time (at compile time, or at runtime in the case of soft coded button lists). variable size and type are not needed, and are there for unnecessary overhead and unnecessary complexity.  


this is one of the the essences of the different way.




Design with ease of modifiiability in mind, but don't do the mods til needed.


With a clean decoupled API, this type of code module can be converted from internal use of array to vector without breaking any of the games or apps that use it.  If you hit that rare case where you don't know how may buttons a screen could possibly have, then go for the vector. until then, avoid overhead, avoid hassle. code for simplicity. code for speed.   wink.png 

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!