Plombo's to-do list

Probably static gif titles, but animated gif titles is another story.  ;)

I even thought about that when Volcanic did that animated menu background, until I realized that it's just script and way ton full of images.
 
Piccolo said:
I recommend Python + Qt  if you haven't tested it yet.

One of these days I will get around to learning to use Qt.

O Ilusionista said:
Plombo, how hard it would be to implement animated gif support for things like data/bgs/title.gif, data/bgs/select.gif, etc ?

Hard enough that I'm not putting it on the to-do list.

SimonSmith said:
O Ilusionista said:
It's already supported.

No, it isn't?  I don't think you understood his question.

SimonSmith said:
Hello Plombo.
Would you mind taking a look of this thread please?
http://www.chronocrash.com/forum/index.php?topic=2006.msg26731;topicseen#new

I'm trying to stay away from the Android port for now.  It sounds like a mountain of headaches.
 
Quote from: SimonSmith on Today at 08:40:54 AM
Quote from: O Ilusionista on Today at 07:49:00 AM
...

It's already supported.


No, it isn't?  I don't think you understood his question.
I think I do...UT has added this feature long time ago.
Code:
#define gep getentityproperty
#define self getlocalvar("self")
void reopengif()
{
	void gif	=	openanigif("data/scenes/"+gep(self,"name")+".gif");
	setlocalvar("gif", gif);
	setlocalvar("giftime", openborvariant("elapsed_time")*5);
	decodeanigif(gif);
	return gif;
}

void main()
{
	void gif =	getlocalvar("gif");
	if(!gif)
	{
		gif = reopengif();
	}
	else if(getanigifinfo(gif, "nextframe")+getlocalvar("giftime")<=openborvariant("elapsed_time")*5)
	{
		if(decodeanigif(gif)) gif=reopengif();
	}
	drawscreen(getanigifinfo(gif, "buffer"), gep(self,"x"),gep(self,"y"),gep(self,"z"));
}
void ondestroy()
{
	void gif = getlocalvar("gif");
	if(gif)
	{
		free(gif);
		setlocalvar("gif", NULL());
	}
	setlocalvar("giftime", NULL());
}

I'm trying to stay away from the Android port for now.  It sounds like a mountain of headaches.
Haha, with the great power comes great responsibility... ;D
 
SimonSmith said:
I think I do...UT has added this feature long time ago.
Code:
...

Oh, if it involves a script hack then that's more believable.

CRxTRDude said:
Qt's also nice as well, lots of apps made using it as well. Although Qt's C++ based and GTK is native C.

Here's a comparison between these two UI systems: http://www.wikivs.com/wiki/GTK_vs_Qt

Rest assured I know all about Qt, aside from its actual API since I've never written an application with it.  I even used KDE as my desktop environment for a short while a long time ago.
 
Okay then. Either way, it's your choice.  ;)

And:

Plombo said:
I'm trying to stay away from the Android port for now.  It sounds like a mountain of headaches.

You don't say. :)

I managed to update the SDL2 static lib for Android from 2.0.0 to 2.0.2 successfully (aimed at 2.0.2 because of the joysticks and accelerometer issues). Problem now is that first, the APK suddenly turned raster on an Android 2.3.3 and second, it signals to stop compatibility to Android 3.1 below since SDL now needs a API higher than 10 for the joystick support. That will totally half the userbase.  :(
 
SimonSmith said:
I think I do...UT has added this feature long time ago.
Code:
#define gep getentityproperty
#define self getlocalvar("self")
void reopengif()
{
	void gif	=	openanigif("data/scenes/"+gep(self,"name")+".gif");
	setlocalvar("gif", gif);
	setlocalvar("giftime", openborvariant("elapsed_time")*5);
	decodeanigif(gif);
	return gif;
}

void main()
{
	void gif =	getlocalvar("gif");
	if(!gif)
	{
		gif = reopengif();
	}
	else if(getanigifinfo(gif, "nextframe")+getlocalvar("giftime")<=openborvariant("elapsed_time")*5)
	{
		if(decodeanigif(gif)) gif=reopengif();
	}
	drawscreen(getanigifinfo(gif, "buffer"), gep(self,"x"),gep(self,"y"),gep(self,"z"));
}
void ondestroy()
{
	void gif = getlocalvar("gif");
	if(gif)
	{
		free(gif);
		setlocalvar("gif", NULL());
	}
	setlocalvar("giftime", NULL());
}

Hum, there are two questions about this:

1- Since I saw main() and ondestroy(), I guess this code is meant to be used in "updated.c". But the code doesn't says WHEN the gif will be drawn on the screen (it lacks triggers like "in_titlescreen", "in_menuscreen", "in_selectscreen", etc), or it will be drawn everytime.

2- This is something I hope DC would fix on his new engine: the lack of documentation. Ok, I am not that old with the engine, but I never saw things like "decodeanigif", "getanigifinfo" and there is no documentation about this.[/code]
 
O Ilusionista said:
This is something I hope DC would fix on his new engine: the lack of documentation. Ok, I am not that old with the engine, but I never saw things like "decodeanigif", "getanigifinfo" and there is no documentation about this.

This is indeed one of the big things that Chrono Crash is slated to fix.  Developers will be required to properly document all commands and functions as they are added/changed.
 
That was the problem as well, UT, as much as he is a good programmer and contributor to the project, had a lot of functions undocumented. When I updated the Android port, he didn't explain compiling, he didn't explain the touch.txt syntax that deep, except searching on the forums. He just placed things here and there without informing how they work.
 
Updated original post with three more tasks:

Plombo said:
  • Finish GUI for tool to create alpha masks from 24-bit PNGs
  • Look into measuring frames per second with better precision
  • Look into alpha masking for bglayer/fglayer (note: will be incompatible with 24-bit bg/fg images)
 
I also have a question Plombo.
I wonder if the speed of script can be executed faster ?
According to my test, compared with javascript, the efficiency of c-script that OpenBOR used is much slow(about 10 times slower).
And I hope I was wrong....



 
SimonSmith said:
....Im also wondering if performance hit wouldnt be too big with 24bit pngs
Well, this is the most important thing I care about...
Without GPU supports, if it's too heavy for CPU.

It is fine.  I doubt the performance will be noticeably worse than 8-bit.  The reason for using indexed color is memory, not speed.

SimonSmith said:
I also have a question Plombo.
I wonder if the speed of script can be executed faster ?
According to my test, compared with javascript, the efficiency of c-script that OpenBOR used is much slow(about 10 times slower).
And I hope I was wrong....

Compared to other languages, OpenBOR script is slow, but that doesn't matter because even for very script-heavy mods, script is generally not much of execution time.

What does matter is memory usage and code size.  OpenBOR's super-minimalistic script engine compiles to just a few kilobytes on any given platform, so it's not occupying valuable memory.  And we try to keep script memory usage down as well.
 
Look into alpha masking for bglayer/fglayer
You are missing one more: layer. Its undocumented (and I forgot to add it to the manual as well). Works like fglayer, you can take a look at the post I got an error with the mirror feature - link
 
O Ilusionista said:
Look into alpha masking for bglayer/fglayer
You are missing one more: layer. Its undocumented (and I forgot to add it to the manual as well). Works like fglayer, you can take a look at the post I got an error with the mirror feature - link

That is interesting, and I didn't know about that command.  Fortunately, though, although I wrote "bglayer/fglayer" for brevity, what I'm actually doing in the code is adding support for adding an alpha mask to a layer declared with any layer command* by adding a separate "alphamask" command which is used immediately before declaring the layer to be masked.  You might recognize this as exactly the same way that alpha masks work for characters. ;)

* By "layer command", I mean any command that creates a layer object in the engine.  This includes background, bglayer, fglayer, layer, water, frontpanel, and panel.  All of those use a common "load_layer" function to actually load the image for the layer, so support for masking only really has to be added in that one place.

...Wow, that turned into a really long-winded and detailed explanation.  Sorry about that.
 
Speaking of the manual and undocumented commands, I noticed that the "alphamask" command (the existing one for animations in model files, not the pending one for layers in level files) isn't in there either.  Do you have a complete list of the commands accepted by the engine for the different text file types?  If you don't, I could provide you with one if it would help.
 
Please, provide me everything you can so I can add it to the manual. If you search for "undocumented" here, you will find many things. Any help with that is very appreciated.
 
Back
Top Bottom