Castle Paradox

[phyrfox]

Greetings and Salutations!

My name is Brian. I would like to introduce to everyone the "next generation" of the OHRRPGCE. After many issues with programming and designing a new system, I am pleased to announce that shortly, within the next month, there should be available a new version of this wonderful engine.

It will be available at no cost to the OHR community, as the original is. Currently, there is no working demo available that shows anything other than the basic capabilities that the system will have. This demo would only work in Linux anyway (would have to be a RedHat compatible system), but by the proposed 17-Mar-2005 deadline there should be a working beta version available for testing.

Information will be posted to my personal site (which only has limited uptime due to random server restarts-- a "feature" I plan on fixing soon). I recommend waiting until at least March before even thinking about asking if there will be a demo available, because it's going to take at least that long to take care of internal testing (which is just checking for obvious stuff).

The demo, when released, should have the following system requirements (this is subject to change at a whim):
CPU: 100~333MHz system (untested).
RAM: Will require 1MB+2.5x RPG file (approximately).
HDD: Most installs will require less than 1MB (no games).
O/S: Windows 95+, Linux, MacOS (probably 9.0+).
Drivers: Recommend OGL or DX (recommend latest versions).
Joystick: If used, at least 4 buttons.
Mouse: Recommend two-button mouse, if used.

Other design notes...

The engine should be compatible with any modern system. The RAM requirement is higher because it loads/decompresses/organizes the file into memory, and then closes the file. The "save" files will probably not be compatible with the original engine's save games, unless I can get documentation from James regarding the format of the save files. I've been given quite a bit of documentation regarding the format itself, enough to reasonably implement an engine, although initially, there will not be sound/music.

If anyone has experience with extracting and using information from the RPG file, I'd like to get together with you regarding a few obscure things I can't quite pin down, such as the BAM format that's bugging me at the moment.

Further updates will be available as things progress. Check back weekly for info.

[Joe Man]

Brian, eh? Might you be Brian Fisher, the original big OHR guy second to James? If so, I'd be happy to use your engine. If not, I'll have to see James' seal of approval on the forums. Then again, I'd like to see it either way.

So, how is this engine better than the current? I can see that it is less limited, and is Linux based, both of which are good. However, are the improvements merely cosmetic? Will I be right to expect a prettier, buggier OHR? Is this the legendary Hamsterwheel James spoke of? All of this would be nice to know.

And to James:

_________________
"Everyone has 200,000 bad drawings in them, the sooner you get them out the better."
~Charles Martin Jones

Last edited by Joe Man on Fri Dec 13, 1957 1:21 am; edited 2,892 time in total

[TMC]

No, of course it is not Hamsterwheel. Thats a completely new engine : )

For more information, you might want to view http://forums.rpgdx.net/viewtopic.php?t=1225

My advice is not to worry about save file compatibility. It's alot of work for little benefit.
_________________
"It is so great it is insanely great."

[Bob the Hamster]

No, phyrfox is not the same person as Brian Fisher, the other half of the Hamster Republic.

This is the first I have heard of phyrfox's planned OHRRPGCE rewrite... I think... I have given out documentation on the RPG file format to a bunch of different people, and I have kinda forgotten who all I sent it to :)

Lots of BAM file format documentation is available at hamsterrepublic.com/dl/BAM.zip

I also have some incomplete documentation on both RPG format and SAV format, which will end up on the wiki eventually.

EDIT: Ah, yes, phyrfox. after reading the thread at http://forums.rpgdx.net/viewtopic.php?t=1225 I am starting to remember talking to you about this via e-mail awhile back.

You might be happy to hear that I have finally decided to release the OHRRPGCE source code. At the same time as the next official update, I will be releasing the sources under the GPL. Hopefully that will be helpful to any porting effort such as yours.

[Moogle1]

:o

[Joe Man]

In that case, may I use the famous "Bob hit James" picture as my av sometime?
Why am I bothering to ask... You never even come to CP... >:)
_________________
"Everyone has 200,000 bad drawings in them, the sooner you get them out the better."
~Charles Martin Jones

Last edited by Joe Man on Fri Dec 13, 1957 1:21 am; edited 2,892 time in total

[RPGCreations]

I look forward to this, seeing as how I got as far as battles with wOHR.


Question though

[phyrfox]

First off... James! I can't believe you're still alive after the marshmellow incident... Glad to know that the source will be available. This means that I can turn it into a true work of art, and I'll just GPL it under the same ideal. That will improve the overall quality of the engine. I'll probably need help at some point anyway, although things are running along smoothly now...

As for other questions...

The current implementation calls for loading the entire thing in memory. The reasoning behind this is that most systems have 128-512MB of RAM they can use. And if you don't have the RAM for it, then Windows (or your favorite OS) will turn it into virtual memory anyway. Eventually I'm going to make the project more complex with a load-on-demand feature, but you've certainly heard the saying "The more RAM you use, the faster it will run." ... This project is no exception. No loading times, no brief pauses going from map to map, no "unlumping" the file to a directory and having it accidently locked by the OS. (I've had that happen more than once).

The 2.5x is a bit high, I anticipate that the actual size will run nearly around an even 2x the project size, but I would rather be safe than sorry. So, yes, 25 MB games may require up to 60MB of RAM to run. This actually depends on the format of the files, since I plan on including a BAM->Tracker-style conversion routine. BAM's will require nearly the same space (if not a bit more), but then there's also the sample tables that will be in there. Additionally, pixels are rendered as 8-bit (but note most sprites are 4-bit, thus a double-increase in memory). There are going to be specific routines to output each tile type, instead of generalized routines (sacrificing size for speed). There's only a handful of routines that will be generalized.

Thanks to the open-source ideas, I can now confirm that the save files will eventually be compatible, although probably expanded somehow to fix some bugs that are left in OHR.

Which brings me to another point. The new OHR will not be buggy, nor error-prone. I've been programming for over a decade (although, admittedly, this is my largest project ever). The advantage I have here is I write code in modules, and I test each module before moving on. Bugs are inevitable, but most likely will be limited to minor logic bugs that should be easily fixed due to the modular nature of the engine (the largest function should not be over 100 lines of code at most, with other functions nestled inside).

The biggest challenge should be, of course, keeping backwards compatibility while fixing the bugs currently in the system. I've taken BugZilla's list of logic bugs into consideration, and I'll be trying to hedge those in as I continue.

Currently there are several issues that plague the system as a whole, which I'll be fixing. Knowing that, when it's all said and done, I don't know the exact timing of the system (around 15 f.p.s?), the current system runs far faster than that (then again, it doesn't do anything yet). There are three filtering systems in place, each one increases the complexity of the calculations involved (and thus, slow down the engine). Enough's been posted about that, I don't want it to be overhyped. Either it'll be liked, or hated. If it's hated, I can remove it easily (again, already set up in a modular fashion).

If it's useful or not isn't much of my concern. I just want everyone to know that something will be coming out, it will be compatible with OHR, and it will be smooth. I'm just trying to see if such a thing would be accepted by the OHR community, I guess, or if I would be better off making something just brand-new.

I will not add support for more maps, more music, more anything, unless it comes by popular demand. My goals for the project is simply to port the engine to new systems.

~= phyrfox =~

Oh, and, of course, I am Brian Fear, not Fisher. Interesting coincidence, though, don't you think?

[RPGCreations]

All I really want at this point is CD playback (perhaps instead of playing the BAM Track #, play the same CD track #, a simple switch) and the graphics modes.

I look forward to using this with Sword of Jade.
_________________

[Squall]

OHR on the mac!? Oh happy day!

Yeah, I'm pretty excited about this. Good luck on it, and I hope everything works out smoothly.

[phyrfox]

I'll think about it as an optional feature (can be enabled via menu options) but that won't be closer to the 2.0 release, which is momentarily unset (with an expected release date near the end of the year). Version 1.0 will have only a few "extras" thrown in (mostly those that would be painfully hard to implement if I made the engine the "other way first").

I need to experiment with various output methods, as current indications are not a healthy suggestion. Note that the numbers are relative to my system, driver configuration, and a variety of other things completely beyond any fixable control at this point.

Here are some quick benchmarks to give people an idea of how this will run (at the moment, I've not yet optimized anything, so the numbers are un-impressive).

Full-pixel skipping, conversion to 32-bbp: 124.
Full-pixel stretching, conversion to 32-bbp: 112.
Full-pixel interpolation, conversion to 32-bbp: 71.

This suggests to me that the system will run 30+ frames per second in the configurations listed on the following systems:

Pixel-skipping: 366MHz.
Pixel-stretching: 400MHz.
Pixel-interpolation: 633MHz.

In addition, I can safely deduce that the engine will run at the "OHR" speed (15 FPS or so) at the following speeds:

Pixel-skipping: 181MHz.
Pixel-stretching: 200MHz.
Pixel-stretching: 333MHz.

I'm well aware that these speeds are not even close to optimized speeds that will be achieved once I advance to hardware-accelerated versions of the same code. It can be safely said, then, that anyone with a Pentium-class system should be capable of running it in the lowest resolution options, and any computer made in the past 6 years should qualify for even the highest resolutions.

Then again, I'm also ignoring the complexities of the engine itself, but I'm fairly confident that the filters will consume 90% or more of the total workload of the final engine, or nearly as much.

Research for the next three days or so is being devoted to bringing these numbers up to at least double the current implementation (at least 250 ideally).

~= phyrfox =~

[jabbercat]

If you are using SDL, expect your fps to cap at around 20-30. There are things you can do to optimize that a little but you're never going to get even close to DX or GL fps. For ultimate port-abilty, go with GL.

[phyrfox]

Right now, my current FPS caps at 80 in the "best resolution mode", and over 120 in the "least looking mode". And that's running all the tile-drawings by software code that I wrote myself. SDL is not as slow as you imagine, looks like. At least, not any more... Maybe not as fast as OGL, but it's easier to implement, and fast enough for purposes I need it for.

~= phyrfox =~

[Moogle1]

...especially since you only need 15 fps.
_________________

Slime Salad :: Independent Game Design

[jabbercat]

80? 120? How? Can I see your blitting code?