[akOOma]

But Lua is only for C/C++, right???
_________________
Keep on codin'
-----------------

-----------------
Just another post to increase my rank...

[Bjorn]

ak00ma

Lua is written in C but I don't think that means it's only possible to use it with C/C++ programs. Never used any of such binding stuff though.

Twinsen

Of course I'm letting Lua do the high level stuff and my engine the low level stuff too, there's not much variation there. I was talking about the way to set such a thing up, and it looked like you had done this rather different that me. For example, I noticed a lot of your Lua statements are not enclosed in a function, while I define functions that will be called by the engine.

With C++ to Lua binding I mean the way I'm binding C++ classes to Lua code, to be able to use and subclass them in the Lua scripts. For example, the TiledMap class defines a tiled map that could be drawn on the Canvas and on the map there can be Actors which have variables for their representation, placing and collision info. I want to be able to use and subclass these datatypes in Lua. If I set for example the x member variable of an Actor, I want the x member variable of the C++ class instance of the Actor to be changed and same thing the other way around. And the same thing should happen when changing the x member variable of an instance of an EnemySpider (as that's indirectly a subclass of an Actor).

I don't know why you think that Lua being meant to extend C++ code has anything to do with calling Lua functions from C++ or the other way around. In my implementation, the engine calls quite a few Lua functions, which will call C in their turn. Basically:

init() - Script initializes should initialize (load tile bitmaps, initialize subsystems, spawn player, etc.)
update() - Script should do a logic update (this call will basically cause an update() call for each subsystem)
render() - Script should display the game state, so it draws the map and HUD basically
load_map() - Called when a map is loaded, in order to take specific actions like populating the map.

Further more, each created Object will get functions called on him from the engine when certain events occur. The most important of this is the tick() function, called every game update. But it also:

function Object:event_stand_on(obj)
function Object:event_bumped_into(obj)
function Object:event_bump_into(obj)
function Object:event_dir_change()
function Object:event_walk_start()
function Object:event_walk_finished()
function Object:event_destroyed()

If you think there's still too much code handled by the engine, I agree. I'm planning to have the walking code handled by Lua scripts too which will get rid of all but the destroyed() and tick() calls.

As for saving, with part of the state present in C++ that won't be as easy as saving a file dump. For example, when loading, the right tile bitmaps will have to be loaded and the entities will have to be created on the map.

[DrV]

Well, if you always write fullscreen apps, then you can probably never use a debugger anyhow, unless you do have a multimon system. Do any of the commercial distros of Linux support multimon with the X Window System? That'd be nice. (I don't have a multimonitor system, but I'm considering getting another gfx card eventually.)
_________________
Don't ask no stupid questions and I won't send you away.
If you want to talk fishing, well, I guess that'll be okay.

[BigManJones]

I've never found debuggers that useful, gdb never helped me out with segfaults at all. Its my firm belief that theres nothing a debugger can do that a few printf can't.

LUA

I have no experience scripting a game (or anything else) but from everything I've read it seems that twinson is doing it like the pros; put all the game logic and 'stuff' in the script and everything else in the dll. But what about 'stuff'? Does this include AI - sure why not that seems easy enough? How about collision detection? How about the user interface? Howabout the GUI? These others don't seem as easy.

What I've been thinking about for the past few month is 1. How to organize your data so its all visible where it needs to be (in c++) and 2. What functions and where to put them in your classes to expose them to the script. Nephilim gave me some great advice here:

http://forums.rpgdx.net/viewtopic.php?t=440

It seems to me that LUA is WAY more powerful a language than anything I would need to script a game.

[Bjorn]

Uhm, 'doing it like the pros' depends on which pros of course. My big example is Epic with their Unreal Engine, a very professional product. They have a transparent way that abstracts from what exactly is implemented natively (in C++) and which parts are implemented in a script. Most classes are implemented partly in both. Of course, in general, things that take a lot of instructions are implemented in a DLL.

As for the 'stuff'...

AI:
Epic has implemented events like seePlayer and hearNoise (accompanied by makeNoise) and more such functions. Allowing the AI to define the behaviour flexibly, but have native code take care of the algorithms that need efficiency or speed.

Collision detection:
An option is to let the engine do the pathfinding and collision detection, but let the script handle the actual events like collidesWith or call the functions like findPathTo.

User interface/HUD:
In Cave Adventure, this stuff is drawn by the scripts. There's actually only one function to put a bitmap on the screen:

[BigManJones]

Hmm, I looked at a couple of unreal scripting tutes a few weeks ago, I see what your saying about high level stuff being in the engine. I was reading the Lua Book today - functions are first class 'objects' and the code can rewrite itself. Thats just crazy. I can't wrap my mind around that kind of abstraction.

It looks like your m_draw_bitmap() function calls either blit or stretch_blit in your c++ code; how does that work exactly?

[Bjorn]

m_draw_bitmap() is actually pretty complicated, I'll post the code below because I am interested in more efficient versions. :-) Although I think when I switch to OpenGL this will be much more easy to implement. The dest_w and dest_h specify the width and height of the area you want to draw to. The src_x and src_y specify the point on the source bitmap that matches the top-left of the destination rectangle. The src_w and src_h specify the width and the height of the rectangle on the source bitmap that will be fit into the destination rectangle. When this rectangle goes beyond the source bitmap, the bitmap will be tiled.

[twinsen]

[BigManJones]

Thats a real feature packed draw_bitmap function. Are there additional set_drawmode_trans and set_drawmode_alpha functions also? I don't see the advantage of tiling the bit_map if the destination is bigger;

For efficiency - there seems to be a few wasted cpu cycles in the condtionals and int x =startx and y assignments but thats nothing compared to stretching and blending. I'm doing alot of stretch_blitting in my zoomer demo, I'm going to check out Fblend, its supposedly 5x faster than allegro's routines (stretch and blending)

I was thinking about OpenGL for this stuff too, only problem is I would have to switch to SDL (well, I wouldn't HAVE TO, but its so much more mature than AllegroGL) All you have to do is set Ortho mode and draw a bunch of textured quads, you wouldn't even have to move the view around.

[Bjorn]

Well, one advantage of the automatic tiling is that you can easily create patterned scrolling backgrounds, like many games used on the SNES. But otherwise, I think it's the kind of behaviour one would expect with such a scheme. The ability to stretch any source rect to any dest rect packs virtually anything you would want to do with bitmaps in one function call. About the transparency, yes that's done with set_drawmode(DM_TRANS) and set_alpha(...) functions.

[DrunkenCoder]

woha! that's one big function.

seems like a bit more than the regular kitchen sink model =)
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP

[Guest]

Well, I haven't been online in a long time, I was banned from the computer for awhile. Anyway, sorry guys, but I've already found a coder for this side project- But DrunkenCoder, or anyone else who's interested, I may have a use for you in the future. Contact me if you'd like to join BlueJAY Entertainment.

[js71]

That guest was me, as you might have guessed.... Or as you might have guest? Harhar, puntastic.