i realized how big the file was when un-UPXed... does UPX support Mac binaries? the engine inflated to 1.6MB.

Oh, masterful! I turn my back for a week or two and suddenly there's a new VERGE. Woop! Not entirely sure about LUA as an alternative language, though: do we really need TWO? Most games makers are quite happy with the one. Other than that, dandy! I'm off to go experiment!

When I was giving LUA a test run, it seemed alright. But when I decided to do a Message Box Test for talking to someone, what it did was open it up, but made it so that the character was still moving around if you were to press the arrow keys, and the message box was still there. I'll provide the code I've used for this, and I'm not sure if I did something wrong.

function TextBox(text)



         while SCAN_ENTER ~= false do

               Render()

               RectFill(5,200,315,235,RGB(0,10,255),screen)

               Rect(5,200,315,235,RGB(0,0,240),screen)

               PrintString(7,202,screen,0,text)

               ShowPage()

         end



end

And also, when I tried to attach 'system.lua' to a resource file, and the engine doesn't seem to recognize it even when it was mounted in the configuration file. I don't know if this was a glitch or what.

EDIT: Use pre tags for code snippets, not the code tag. The code tag is for non-indented, single-line code, for use in the middle of a body of regular text. Also, you didn't close your tag properly. ;_; -- Overkill

I did what you suggested, and it still has problems. It has no problem running, BUT...the message box just sticks there to the screen and never seems to go away. Even if you move around, it's still there. And thanks for the LUA tip, this is practically my first program scripted with LUA.

Quote:Originally posted by spaceseel

I did what you suggested, and it still has problems. It has no problem running, BUT...the message box just sticks there to the screen and never seems to go away. Even if you move around, it's still there. And thanks for the LUA tip, this is practically my first program scripted with LUA.

This is also not Lua specific. Sounds like whatever you do directly after the message box doesn't clear or refresh the screen at all. Make sure any loops have the following inserted before a ShowPage:

RectFill(0, 0, ImageWidth(screen), ImageHeight(screen), 0, screen);

ShowPage doesn't clear the screen, it just refreshes the screen. So if you want the contents to be wiped, there either needs to be a map active and calls to Render(); in your loop, or you gotta draw a rectangle over the entire screen to clear things properly. Put a RectFill directly before a Render, and that way, it'll draw a solid color when you have no map, and draw the map if there's one visible.

So here's a correction to my code:

function TextBox(text)

         while not key[SCAN_ENTER] do

         -- Even better, so people with gamepads can use this:

         -- while not b1 do

               RectFill(0, 0, ImageWidth(screen), ImageHeight(screen), 0, screen) -- Draw black.

               Render() -- Draw the map over the black if there's one open.

               RectFill(5,200,315,235,RGB(0,10,255),screen)

               Rect(5,200,315,235,RGB(0,0,240),screen)

               PrintString(7,202,screen,0,text)

               ShowPage()

         end

end

Because more than just Lua was added to the engine in those two years? Also, a lot of extra libraries are linked into Verge, like Audiere, Corona, zlib, and boost. I dunno. Does executable size really matter that much?

Quote:Originally posted by Kildorf

Also, remember that the .zip up there contains maped, chrmak, and so on in addition to the main enginei was pertaining to an unUPXed engine only. not the whole zipped file release.

Quote:Originally posted by Kildorf

. The .exe itself is only 636k unzipped.when UPXed.

Quote:Originally posted by Overkill

lot of extra libraries are linked into Verge, like Audiere, Corona, zlib, and boost. I dunno.with Audiere as alternative sound engine, why does the engine still look for the fmod?

Quote:Originally posted by Overkill

Does executable size really matter that much?with all the addition to the engine i was happy that the fresh-from-the-zipped-file-release is just 636KB. but when i further "investigate" it was just UPXed (which is a very helpful tool tho.)

the size is not too bothering. it's just that i was hoping that without FMOD around, the engine will work since Audiere is "packed" as alternative.

Thanks for the feedback guys, I'll look into this stuff this weekend

Pretty much any Lua entity variable can't be set. The following variables documented as read/write, can be read, but do nothing when written to:

entity[e].x

entity[e].y

entity[e].specframe

entity[e].face

entity[e].speed

entity[e].visible*

entity[e].obstruct*

entity[e].obstructable*

* In addition to not being writable, they return 0/1 instead of true/false, which is bad because both 0 and 1 evaluate to true in Lua. Try and look for all the other variables where this happens.

The following Lua entity variables need implementation for both read and write operations, and trigger errors:

entity[e].chr

entity[e].lucent

entity[e].framew --zero: this is actually rdonly

entity[e].frameh --zero: this is actually rdonly

entity[e].description

The following new functions don't exist in Lua:

bool SoundIsPlaying(int channel)

void RectVGrad(int x, int y, int x2, int y2, int c, int c2, int dest)

void RectHGrad(int x, int y, int x2, int y2, int c, int c2, int dest)

void RectRGrad(int x, int y, int x2, int y2, int c, int c2, int dest)

void Rect4Grad(int x, int y, int x2, int y2, int c, int c2, int c3, int c4, int dest)

string WrapText(int font, string s, int line_width)

int HSV(int h, int s, int v)

int GetH(int color)

int GetS(int color)

int GetV(int color)

HueReplace(int hue_to_find, int hue_tolerance, int hue_replacement, int image)

void ColorReplace(int color_to_find, int color_replacement, int image)

There are probably more things than this that still need implementation/boolean fixing. Go go go!

The engine is bigger because

1. audiere brought in a lot of code, including decoders for: mp3, ogg/vorbis, and flac. I just now took out speex which is a useless waste of space

2. additionally, there is support for module repacking (so soundtracks with samples shared across several mods can remove the redundancies). this uses flac also. for information check http://www.pi-r-squared.com/code/garlick/

3. lua was added along with a bunch of verge<->lua binding code (much of which is buggy at this point!). This also involved adding another layer of indirection between the verge core routines and the script bindings, as a bunch of logic used to happen in the verge<->vc bindings, and it needs to get factored out into common binding logic--while even still the verge<->vc bindings must remain for some other reasons. Thats a little bit of code for every global function or variable, of which there are many..

Also, I use LuaBind to do some of the binding work, which uses boost, and therefore is hilariously bloated.

4. one last thing--the release build is optimized for speed, instead of size. the upxed size could be 100k smaller if you didnt mind it running X % slower

I dont know why the mac version is bigger, thats not my business. but I imagine its for the same reasons as the windows build.

-----------
I neglected to permit fmod.dll to be optionally delay-loaded. That will be fixed in the next build.

FMOD is still in the engine, which takes a bit of space. I am waiting on feedback for whether we need fmod anymore. I'll take it out later if it seems nobody needs it. For now it is still the default.

To specify the use of audiere, put soundengine 2 in your verge.cfg. If you do this, fmod.dll will not need to be present. If you do not specify soundengine anything, or do specify soundengine 0, then fmod will activate and fmod.dll will be needed

I agree with you guys that a lean and mean distributable package is aesthetic and professional. I love to see the exe small and no unusual non-system dll dependencies.

In fact, I have this crazy idea to concatenate all the other files in a directory to the end of an exe and then memory map it and do file i/o from "memory" (actually read from the end of the exe as needed)........ thatd be a super cool one exe deployment, as long as you were positive it wasnt going to force all the data files to load along with the executable