ZDoom

The draw functions are not tested yet. I'll need them for the menu which will also be used to test their functionality. But I needed this stuff somewhat operational to start.

If you want to see how they are used, check the C++ source.

TAG_DONE is not exported, and using it without TAG_DONE causes an exception.
Why is TAG_DONE needed in ZScript anyway, if you can tell the argument count directly?

Anyway, passing 0 as TAG_DONE works for now.

Turns out the only way to draw them right now is with powerup's DrawPowerup function...

ZZYZX wrote:TAG_DONE is not exported, and using it without TAG_DONE causes an exception.
Why is TAG_DONE needed in ZScript anyway, if you can tell the argument count directly?

Anyway, passing 0 as TAG_DONE works for now.

Like I said, it hasn't been tested yet. I want this to work without TAG_DONE, because a VM function knows the amount of parameters it gets. There's probably some other issues present, too.

Pretty sure if you hack around with named function arguments (I remember there's such thing?) it's probably possible to omit using tags altogether. Just a random idea. I personally don't feel like extending varargs to named arguments if anything :)

P.S. http://pastebin.com/RUKRBCSh
Produces results like http://i.imgur.com/lOXhXOx.png
Going to randomly use this while streaming on twitch :P

(also whoever is interested can take an example of calling DrawText from there, for people unfamiliar with how text rendering has always worked internally)
(ignore the class, what you need is inside the RenderOverlay function. with current GZDoom's codebase, you can override DrawPowerup method in Inventory or Powerup subclasses)

Just a quick warning: The dynamic array code I just committed is not finished yet! While I verified that the code generator is doing what is needed, the backend for the arrays does not exist yet, they will leak memory and may even crash!

I'll hold off until you give the all-clear.

ZZYZX wrote: (also whoever is interested can take an example of calling DrawText from there, for people unfamiliar with how text rendering has always worked internally)

I see that you are setting the screen's virtual width and height twice to achieve different text sizes? Will this be the only way or will there be a more convenient way to simply specify the size of the text?

Nash wrote:

ZZYZX wrote: (also whoever is interested can take an example of calling DrawText from there, for people unfamiliar with how text rendering has always worked internally)

I see that you are setting the screen's virtual width and height twice to achieve different text sizes? Will this be the only way or will there be a more convenient way to simply specify the size of the text?

GZDoom does it that way.

Nash wrote:

ZZYZX wrote: (also whoever is interested can take an example of calling DrawText from there, for people unfamiliar with how text rendering has always worked internally)

I see that you are setting the screen's virtual width and height twice to achieve different text sizes? Will this be the only way or will there be a more convenient way to simply specify the size of the text?

DrawTexture and DrawText are low level functions. This is what sits at the very bottom of all 2D rendering in the game and makes no assumptions whatsoever. It requires explicit specification of any option you need.
For higher level output it is normal to wrap this into helper functions that do the necessary bookkeeping.

Saw in one posts the use of the "player" and "playeringame" arrays. Are them builtin?

Yep, those are built-in globals.

Once the event system is in I could write a proper library-like wrapper for the drawing functions and contribute that to the ZScript library, with SetHudSize, and overall more ACS-like interface.
I don't think this should belong to the core library anyway.

ALSO: I heard there's some way to create a class instance using new or smth.
How do I make a class that's not possible to 'new'?

So out of curiosity, Graf, what will the type system overhauling amount to besides memory reduction?

Maintainability.. That thing was crashing so often during development that I just got tired.
I'll never understand why Randi cooked up a system where the type descriptors for the garbage collected objects are themselves garbage collected, with some circular dependencies. I've got it now to a state where all the backing data is guaranteed to not to be touched by the GC ever, so that a complete takedown will no longer resuit in random crashes if I just happen to change the wrong thing.

This was because making the menu items objects caused some random GC related crashes but the over 9000 objects that got allocated during script compilation made it impossible to find what was wrong.