Search results

Still busy, but found time to commit some work I'd already done. As of r4096, you can now use alpha masks with level layers/backgrounds!  Here is a description of the new alphamask command: All of the details of alpha masking, such as the mask format, are the same for layers as they are for...

Yes, this is an accurate description of what it is doing. Other functions don't need an extern like that because unlike openbor.c's playgif function, they are declared in included headers. You just read the function carefully and look at what it is doing with the parameters.  For the case of...

Thanks!  I will try to get through okay. :) The way you interpret any HRESULT is that a function returning S_OK means it succeeded and returning E_FAIL means there was some error.

Hi everyone.  It might not be necessary to say this, but don't expect any progress on this stuff during the next week or so, as I'm very busy IRL.  I'm not disappearing or anything like that, and I will probably at least pop onto these forums occasionally during that time. :)

Here is the giant list, then. ;D *Edit* Added the list of script functions for good measure.

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...

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...

It is fine.  I doubt the performance will be noticeably worse than 8-bit.  The reason for using indexed color is memory, not speed. 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...

Updated original post with three more tasks:

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.

Oh, if it involves a script hack then that's more believable. 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.

One of these days I will get around to learning to use Qt. Hard enough that I'm not putting it on the to-do list. No, it isn't?  I don't think you understood his question. I'm trying to stay away from the Android port for now.  It sounds like a mountain of headaches.

I don't make enough GUIs to really have a standard for creating them.  This time, I decided on a whim to try out Gtk# (.NET/Mono), which was a bad idea because the documentation for Gtk# is so scarce that it makes OpenBOR seem well-documented by comparison. I do generally like GTK though, and...

So I just spent the last 6 hours working on a release-worthy version of the aforementioned software.  The actual image manipulation program is all ready to go in the form of a lightweight command line program, but people always demand graphical interfaces for these things, so I've been working...

I'm planning to add support for in-game backgrounds at some point.  Characters, though, are staying as they are for a variety of good reasons.  In addition, 24-bit PNGs in backgrounds won't support a full alpha channel, and might or might not support regular drawmethod alpha blending. A better...

Sure, here's a Windows/Linux build: OpenBOR v3.0 Build 4094

As of r4094 a few minutes ago, 24-bit PNGs are now supported in 32-bit color mode for these static backgrounds.  So your data/bgs/title.png, data/bgs/select.png, etc. can now be true color PNGs as long as the color depth for the mod is set to 32-bit.

It's "Your source for useful modding tools".  No need to reinvent things that existing programs already do well. ;) By time they're drawn to the screen, they're not PNGs anymore - they're 32-bit (PIXEL_32) screen objects in memory.  They work the same way as regular 8-bit (PIXEL_x8) screens as...

The PNG format already has support for an optional 8-bit alpha channel in 24-bit RGB images.  You can easily create such PNGs in GIMP or Photoshop. If a fully customizable alpha channel is all you want, it should already be doable with alpha masking, no? There would definitely be a...

Well, I looked into it.  Here's the rundown: For static backgrounds (title screen, loading screens, etc.) it should be doable with a bit of work.  In 16/32-bit mode, these use a global s_screen variable called "background" with pixelformat PIXEL_x8, and loading one of these backgrounds just...