Re: [Scrupp-devel] Lua Scrupp

[Andreas K. <and...@gm...>]

Hello Francisco,

it's very nice to hear from someone who is actually using Scrupp :)

> I'm very interseted on Scrupp to substitute the graphics sub-system in
> my project.
> Take a look on: http://thesynchronousblog.blogspot.com/

Hey, that's a cool idea. The video was surprising!

> I already integrated it and the results are good, specially taking
> into account that I'll gain in portability.
> The only exception is for text drawing, if I understood the concept,
> I'd have to create some new images on each frame (think of a
> scoreboard).

To speak about portability: At the moment, I'm preparing the next
release. The port to Mac OS X is nearly finished. It needs some more
testing on Intel Macs only.

Yeah, I know, the text drawing is kind of awkward. In SVN there are two
changes I made:

1. The image:render(table) function checks the argument 'table' for a
"color" entry. Now it's possible to colorize an image. This way it's
sufficient to provide a white font image. It can get a color during
rendering.

2. A new Lua plugin: font.lua (located in the scripts directory)
This plugin caches nearly all the letters of a given font at a given
size. To print a text, it is split up into single letters an each one is
rendered separately. New (i.e. not cached) letters are cached on the fly.

> I'd like to make some suggestions, please take those that you agree
> and ignore the others.
> I'm not a graphics expert, so some of them might not make sense.
> 
> Sorry for the long list, but shows that I'm really using it.

Thank you very much for the list! Find my detailed answers below.

> ===========>
> 
> Here I go:
> 
> 1) SCRUPP:
> - The scrupp executable should respect the LUA_INIT variable (and what
> else the lua interpreter does).

Agreed.

> - I'd like more "scrupp" than "game" for its namespace.

Agreed.

> - Is it possible to resize the main window? Like a normal X11 application.

Do you mean resizing by clicking and dragging the mouse on a corner of
the window? I don't know, whether SDL supports this. I'll have a look at it.

> - I expected a game.getWindowSize(), to be similar to the image API.

Agreed.

> - Does game.addImage() uses cached object for duplicated paths? (I
> don't need that, I'd rather do it by hand)
No and it's not planned either.

> - game.addFile() should return the values returned by the executed file.

Already implemented in SVN.


> 2) CALLBACKS:
> - A function to set the desired dt. For example, setDT(0) would be
> good for benchmarking.

In SVN I changed the default framerate to 100 fps (image movement
becomes smoother). I think it's good idea to let the user change the delta.

> - Callbacks could accept tables, I use it a lot with the __call metamethod.

Agreed.

> - I'd have some use for timers if they could be implemented
> efficiently in your system.

I think this should be implemented as a Lua plugin (see animation.lua or
font.lua in the scripts directory). I will have a look at it.


> 3) MOUSE / KEYBOARD
> - A new callback for mouse moving.
>    Then I wouldn't need x,y positions when button is pressed.
>    Instead, I'd use a motion event such as:
>    mousemoved (x, y)
>    Where x,y corresponds to the new mouse position.

Scrupp assumes that the mouse is moved in every frame. You could do the
following: In the main.render function you get the mouse position via
mouse.getX(), mouse.getY() or mouse.getPos(). Then you compare the new
coordinates with the ones from the last frame. If they have changed,
call mousemoved(). This way Scrupp doesn't have to be changed :)

> - Why not use strings for key codes? (I think this would be more the Lua way)
>    keypressed (key) would receive 'a' instead of key.a

Well, many key can be represented as strings, but not all. What's the
case with keys like tab, escape, F1 and so on? One possibility might be
to map all keys representing ascii chars to strings (chars) and the
others to longer strings ("escape", "tab", "F1", ...). Any ideas?

> - Moving "mouse" and "key" to "game" namespace would make the module cleaner.

I will think about that.

> - "key" looks like a single key, I think "keyboard" would be a better name.

I chose "key" because it's shorter and I liked phrases like
"key.isDown(k)" or "key.a".


> 4) GRAPHICS:
> - I'd like to have support for image scaling, maybe as a parameter
> when calling render.

Yes, I plan to support this. Yet I don't know how the interface should
look like. Scaling needs some kind of reference point.

> - I think a game.drawText() would do better, instead of an opaque object.
>     Maybe using objects only for the fonts.

I removed font:print() in SVN. Now it's only possible to use
"generateImage". As I wrote earlier, the font plugin is the first try to
simplify this. You could implement game.drawText() yourself in Lua using
the plugin.

> - The game.draw() API is not good for animated lines or rectangles.
>     It could accept two extra parameters (dx,dy), so that all points
> are translated relative to them. Another option would be to assume
> that all points have their values relative to the first. Then the
> first would be the only absolute value in the list.

game.draw() expects a table, where all points are listed in the array
part. I think it should already be possible do write a Lua function
which changes all these points somehow. Example:

function translateTable(table, dx, dy)
	for i=1,#table,2 do
		table[i] = table[i] + dx
	end
	for i=2,#table,2 do
		table[i] = table[i] + dy
	end
end

=======================================================================

On which platform do you use Scrupp? The next release of Scrupp might
take some time. Writing documentation is not as much fun as programming :)

Maybe you can use the SVN version of Scrupp. You can find the logs with
the changes at:
http://scrupp.svn.sourceforge.net/viewvc/scrupp/trunk/?view=log

(version 0.1 was revision 6)

I will change Scrupp according to most of your suggestions.

I send this reply to the Scrupp mailing list, too.

Kind regards,
Andreas