Castle Paradox

[Blue Pixel]

yes! now i wont have to use npcs for overlaps!
_________________

[Mike Caron]

[Newbie_Power]

You could probably prioritize the layers. It would do layer 0 first, then make walls based on layer 1, ignoring layer 1 tiles that do not have any wall flags, then finally do layer 3 wall mapping.

[J.A.R.S.]

[Artimus Bena]

Ahhh, the very first thing I ever said when I first tried the engine was I'd love for it to have layers. Wonderful, mike, just wonderful.

(The second thing was the destruction of BAM)
_________________
SACRE BLEU!

|||Compositions!
|||Eldardeen Soundtrack!
|||Red Mercury!

[Rinku]

This is a good improvement, and 3 layers should be more than enough for anyone, but it's still behind what other engines can do. Just to put this in perspective, the Game Maker for instance can create an infinite (arbitrary) number of layers, each of which can use an arbitrary tile size or even mixed tile sizes, each can have a level of transparency, and you can even make them constantly moving or apply parallax scrolling to them, and you can enable and disable them at any time during play (which is useful if you want to have, say, disappearing ceilings as in the early Dragon Warrior games).

To answer JARS's questions, the Ohrrpgce is still coded in QuickBasic I believe; it's just a more modern version of it that supports Windows. The language itself doesn't really matter though, because the Ohrrpgce is interpreted; if it were coded in C++ it'd probably be no faster than it being coded in QuickBasic.

EDIT: I just saw that this question was answered, I only saw the first page of this thread, I didn't see that there were three pages.

EDIT EDIT: WOW, I think that's about as negative as we'll ever see James Paige. Any more negative and the universe would destroy itself in surprise.
_________________
Tower Defense Game

[PlayerOne]

I'd guess the default passability should always add all 3 layers. That is, a higher layer should add walls, but not take any away.

[Newbie_Power]

Rinku is all kinds of wrong.

OHRRPGCE is not interpreted. It is compiled. Before the Windows releases, it was compiled with QBasic 4.0, which allows compilation into .exe files instead of basic interpretation like the QBasic that comes with your Windows 95 CD forces.

If it were interpreted, we would be running custom.bas into qbasic.exe instead of clicking an .exe file.

And it now uses FreeBasic as its programming language.

[Rinku]

I'm not talking about the Ohrrpgce itself, I'm talking about *games* made in the Ohrrpgce -- those are interpreted (via the Ohrrpgce). Plotscripts are not compiled.
_________________
Tower Defense Game

[Newbie_Power]

*re-reads your post*

No. You were definitely talking about the OHRRPGCE itself.

[Rinku]

I still don't see how you're misreading it. It's kind of obvious that I wouldn't mean that the editor itself isn't compiled. But if this is any clearer: the language used to create the Ohrrpgce engine itself doesn't determine the speed of Ohrrpgce games, because it's an engine that works through interpretation of those games.
_________________
Tower Defense Game

[Newbie_Power]

It still would. For one, we have Windows support now. Two, if it were coded in C and was heavily optimized, it might render games' graphics much faster.

You are confusing the programming language that OHRRPGCE was written in to how it reads data. Yes, it interprets plotscripts, but scripting languages in general are like that anyway. The game itself, however, would be loaded into ram, including the plot scripts that were compiled into the .rpg file. If the game were interpreted, game.exe would be constantly checking the .rpg for that new graphic, which searching the hard drive would be MUCH slower than just getting it from RAM. You can tell that a game is loaded into RAM when some of the larger ones take longer to load at startup.

[Rinku]

As far as I know, Windows programs are no faster than DOS programs, it's not the operating system that determines a program's speed. And, I believe the Ohrrpgce uses the Allegro Library (I heard this mentioned once?), which is what handles the drawing, and that library would work no faster if it were called from C than if it were called from FreeBasic or from anywhere else. Even if it doesn't use Allegro, it probably uses some external graphics library, perhaps even DirectX, and those are independent of the language.

By game, in your second paragraph, do you mean the game resources, or the game logic? I don't really follow your second paragraph, could you rephrase it?
_________________
Tower Defense Game

[Newbie_Power]

The point is, FreeBasic is faster than QBasic simply because it can use SDL or Allegro to access the hardware in ways that QBasic wouldn't do as well at, and it's a 32-bit programming language, meaning that it would take advantage of processors a lot better. C and FreeBasic are both better than QBasic, and you were using C as an example, so I followed along.

game.exe IS the game logic, and it is compiled. The .rpg files are data for game.exe to play with.

[Rinku]

I didn't mean that FreeBasic isn't better than QuickBasic (it never used QBasic, to my knowledge), it was a good idea to move it there.

A lot of the .rpg data is pretty logic-related. For instance, data which leads one textbox into another, data which determines which NPC appears where and which textboxes they link to, door linking data -- it's still interpreting that data into the rules of the game. Technically it's just numerical data that the compiled code reads and uses, but technically anything on the computer is numerical data, including compiled code. There's no real difference between interpreting a plotscript and interpreting a bunch of numerical textbox connection "fake plotscripting" data. I doubt the change to FreeBasic from QuickBasic had any appreciable difference in the speed of either of those kinds of interpretation.
_________________
Tower Defense Game