A feature as big as making everything animate and move properly is bound to have a few bugs in it. There were a couple issues where moving map objects could cause a crash. Those have been fixed, plus a few more minor problems.
Maps that are almost as big as the display window will no longer overlap the scroll bars.
The “blurry” look of the tile palette has been cleaned up.
But here’s the real interesting one. Just when I thought I knew all of RPG Maker’s graphical quirks, it hits me with something like this:
Take a look at the top three rows. One pair of water tiles and three pairs of border tiles are switched around. Turns out that the way RPG Maker stores its tiles in the tile palette doesn’t quite match up with the way it stores the tile data in the database. I wasn’t aware of this, which led to some issues with moving map objects getting stuck on terrain they should have been able to cross. I’ve fixed the tile passability problem, since that was a lot easier than rearranging the tile order to match RPG Maker’s, which would have probably introduced new bugs.
Is TURBU supporting linux? Or at least will it work on Wine? Because I am very interested in this project and would to ask that.
If you planning native linux release, maybe it’s good choice to convert project into Lazarus project instead of using Kylix?
Oops, forgotten about something. Will be possible to use any-sized sprites and 32bit graphics, like in XP? Resolution can stay for me at 320×240, but it would be great to make possibility to change it to 640×480 (with supereagle or hq3x maybe?) As future goals I’d like to see possibility to use XP tilesets or infinite tiles (projectdir/tiles and setting what tile belongs to what tileset in db). Unlimited, or semi-unlimited (30 or so) map layers would be also great, but don’t want another vx with one tileset for whole game (sic!)
Official Linux support will come eventually, once I have a compiler that can handle it. I’ve been asked about using FPC before, and the answer is still the same: it just doesn’t have the features that I need. When FPC can handle Delphi-style generics, anonymous methods and extended RTTI, and Lazarus can do frames and visual form inheritance, I’ll take a more serious look at a Lazarus port.
As for Wine, I honestly have no idea. Why don’t you try it out and let me know? I had some reports that the original POC game engine didn’t work under WINE, that it had trouble with the D3D framework. I’ve since replaced it with an SDL/OpenGL backend, which I’d imagine is a lot more Linux-friendly.
And WRT the graphics, yes to pretty much all of it. The current engine should be able to handle 32-bit graphics, though I haven’t tested that part too much. (Although the blank-screen shield logo is 32 bits and it displays fine.)
Tilesets are implemented in a different way as RPG Maker 2000/2003. Instead of the basic grouping unit being the tileset, it’s the tile group instead. A tileset is basically a collection of tile groups, and can contain as many of them as you want. Each map can only have one tileset, but you can have as many tilesets in the game as you need.
Yeah, but i meant that in xp you can have as many tiles in tilesets as you want, and in 2k3 tile count is limited. I know that RPG MAKER 2k(3) have it, but TURBU only imports lmus and convert to own format, right? So what is stopping you from using unlimited size chipsets, or replacing chipset selection combobox with list where you can add as many chipsets as you want? The structure of tile would be like that:
TTile=record
chipsetid = longint; //chipset id from list in map proporties
layer = boolean; // onebit variable, because we have only two layers now
tileid = byte; // tile id from chipset
end;
Yeah, i am delphi/programmer too. Lazarus actually HAS frames and RTTI components (you need some time to get use to it, but after all you’ll be able to do whatever you need). As for FPC i don’t know if it has anonymous methods. If you want delphi-style pascal, you need add {$MODE DELPHI} (or {$M DELPHI}, i don’t remember) at very beginning of every sourcefile. Perhaps that directive with OBJFPC also can do the trick, but i’m not sure.
Well, the source code is available at http://code.google.com/p/turbu/ if you want to take a look at it. The tile definitions are in turbu_tilesets.pas, but they’re a bit more complicated than that. They don’t define individual tiles, but tile groups, which makes it easier to work with, and yes, each tileset can contain as many tile groups as you need.
So Lazarus has frames now? Cool! And I’ve seen the RTTI Controls, but those are based on “Published properties” RTTI. What I meant was “Extended RTTI,” the full reflection API introduced in Delphi 2010. Basically, when FPC can compile really complex stuff like Alex Ciobanu’s DeHL library, (and when it gets support for BPL-style packages, which TURBU uses pretty heavily,) then I’ll be able to look at a port more seriously.
I’ll lok at that. Can you separate LMU and LDB readers from whole project, because I’d like to start making RTP Dependency scanner for 2k3 (the old one for 2k didn’t notice battle2, battlechara, etc. resources)?
OMG! I misspelled look to lok. I am ashamed, since I don’t make such stupid errors.
Yes. The LMU, LMT and LDB units can be pulled out easily enough, since they were around before I built the editor. They’ve got a bunch of dependencies of their own, stuff like the Events unit, the BER compressed integer reader and the various data types, but they ought to be pretty much independent of the rest of the TURBU code. If you have Delphi 2010 you shouldn’t have any trouble compiling them.
Can you prepare those units for me, because I using Lazarus I need to have one reader because I want to make that dependency scanner (and there is no need to use LMT, LMU and LDB should be enough). Can you prepare it so I can compile them on Lazarus?
Anyway – Did I understood good that there will be no events and all will be have to write in pascal? Because it’s pity and for some non-programmers not acceptable. At least please make event-style code generator (you already make event import, so it shouldn’t be hard).
No, actually you misunderstood completely. There’s an Event Builder system very similar to RPG Maker’s events, but more flexible. Under the hood everything runs on RPG Script, a Pascal scripting engine, and Event Builder events know how to translate themselves into RPG Script code, but that all happens behind the scenes.
Or if you’re a programmer and you want the extra power, you can code your events directly in RPG Script instead of using Event Builder. Both options are available.
Thanks for the info. I just don’t want another Sphere.
Oh, and if translation is in run-time I have serious concerns about Event perfomance vs. RPG Script performance (example – rpg maker XP, less vX)
Please also check mail – I sent you specification what i need.
Yeah. Don’t worry about event performance. Making everything work quickly is a top priority. Part of the problem with RMXP/VX is that it uses Ruby scripting. Ruby is based on Perl and inherits a lot of its problems, including being slow to parse. It’s even been proven that syntactically valid code exists in Perl that can’t be compiled in a finite amount of time. (Not sure if the same problem exists in Ruby, though, but it wouldn’t surprise me.)
RPG Script is based on Pascal, on the other hand, which is about the fastest-compiling language ever created. In my tests, translation from Event Builder to RPG Script code, and compilation of RPG Script code into the native bytecode format both happen instantaneously, even for large scripts.