Castle Paradox

[NeoTA]

that's my description ( i am lj user dgowers).
it seems fairly obvious to me that what occured in that entry was that fyrewulff asked for some info, and i gave it to him.

ysoft, you could adapt my password-decoding routines. or write one based on the documentation in rpgformat.txt

[TMC]

Heheheh.... I noticed that, but forgot to mention that in my reply : P

I am just going to deny access if a password is present, rather than trying to match up with user input (as in I don't know how it is stored, I just examined the RPG file to discover how to tell if a password is present/not)
_________________
"It is so great it is insanely great."

[Ysoft_Entertainment]

um... this thread is closed, but thanks neo, your info was very helpful on how the tilesets and backdrops were encoded, as for the password check, I think it would be useless because well, if a person wants to steal graphics, he can find a way to do so, but I made it so that you have to unlump the the rpg file first. maybe I will add the password checker in the complete version of the program, and well, those who already have tile exporter would still want the complete program, and thats where I will implement password verification system(if I find out how to check the password)
_________________
Try my OHR exporter/importer.
OHRGFX
Striving to become better pixel artist then Fenrir Lunaris. Unfortunately the laziness gets in the way of my goals.

[TMC]

Hmm? What do you mean by closed?

I hope you don't mind, but I am coding my own tile exporter out of fun in assembly. Assembly is something I've wanted to learn for a long time, and now I even already have a program to write! Don't take it as an insult to your program or anything. (Then we will have a range of 3 programs for exporting tilesets/backdrops. We ought to compete : P)

BTW, when you do get the password encoding, tell me, always something useful to know. Like I said, I can only check whether a password is present right now...
_________________
"It is so great it is insanely great."

[junahu]

And an inevitable byproduct of that will be a utility to show the password for password protected files (will be much more likely if you make the source code available to others).

I look foreward to the ensueing privacy invasion.
_________________

[Ysoft_Entertainment]

hmm. I don't mind at all. go ahead, may the best one win.
except mines will be able to export every graphic out of ohr.
as for password, its easy to see whether it is present or not, its hard to decode one
_________________
Try my OHR exporter/importer.
OHRGFX
Striving to become better pixel artist then Fenrir Lunaris. Unfortunately the laziness gets in the way of my goals.

[TMC]

junahu, are you accusing me of having intent to write such a program? I only asked Ysoft to tell me, not pass on password information to everyone.

As for exporting all graphics... I'm only going to give it as many capabilities as I can fit in 1kb...
_________________
"It is so great it is insanely great."

[Bob the Hamster]

[junahu]

I GOT to stop typing the first thing that pops into my head

I mean that was just plain STUPID of me!

I wish both of you the best of luck with your utilities.
_________________

[Solsund]

After a long absense from this community I decided to hop back in to say a few things.

One of the password extracting programs that James is referring to was probably the one I wrote a long time ago. I never released it directly to the public but I gave him a copy to check out, if I remember right. I'm pretty sure the password routine has changed in the mean time. I only used to for learning purposes (really!) as I was working on figuring out how the OHR engine worked.

What the OHR community needs in my opinion is a utility that allows you to remove the extra items found inside your RPG files, such as tilesets that got added as backdrops, without messing up the huge mass of links that keeps the whole system working properly. It may be possible to do this inside custom.exe now, I haven't had to time to fully dig around inside the new version.

I have been working on a project that uses the OHR as a test system and I planned on giving the source code over to James for possible use in OHRWheel, if he feels it's useful. It's a set of C++ classes that work together to treat a .RPG file as it's own miniature file system and read/write to the files inside directly rather than having to unlump them. It has the ability to have multiple files inside the .RPG file open and once and read from them in any order without freaking out. It can also unlump parts of the file to the disk, or even the whole file, and continue working with it in a way that is transparent to the coder of the program.

It's not fully working yet as it can not yet write to files, handle files in text mode or actually stick the files out to the disk, although the support is still in the code for it all. Once I have the system itself setup I plan on making it a virtual class that others can use as a base class for their own filesystems.

I got the idea after getting tired of unlumping .RPG files to work with them and also when I saw that Moogle1's RPGACE (I have no clue if he is still around) used about a thousand tiny files all sitting in a directory, for each game. It seemed a waste and I knew programs could do direct reads as that's how Starcraft's .MPQ and quake's .WAD files worked. It's been a design in my head for at least five years and now that I made it back to college and have been programming again it just started to come out.

Here is a little demo it, very limited.
Requires DirectX of some sort to be on your computer and is hardcoded to use Wander.rpg.
http://gameguru.freeservers.com/techdemo/index.html

Let me know what you think, Will this type of functionality be useful?
I'd love to hear your ideas.

[Bob the Hamster]

That sounds really cool. I look forward to seeing it.

I have no plans on adding RPG file support to HamsterWheel, but routines like that sound very useful for RPG file manipulation utilities.

[Ysoft_Entertainment]

I make my own routines in vb, well actually functions. they work pretty cool, I got the ohr palette using the bmp picture, the 16 color palette using almost same method, and the 4-bit bmp saving using the program that I converted from Qbasic, and they work, the 4-bit bmp saving took me long time to understand. but all in all it works, and when I learn enough c++ I might port the extractor to it, so that it will be able to be multi-platform.
_________________
Try my OHR exporter/importer.
OHRGFX
Striving to become better pixel artist then Fenrir Lunaris. Unfortunately the laziness gets in the way of my goals.

[Solsund]

Hey James,

The .RPG support is just for now because I need a file format I already know to test it out with. The only function right now that is .RPG file specific is LoadFileSystem - That loads the locations of all the files found inside. The idea is that function would be virtual so that someone else can make it load their own system.

That way anyone who works with large batches of files can splice them all into one file and work with them inside that file without having to worry about the handling for it. I'm still not 100% sure how I'm going to handle file writing as if the file grows outside it's boundaries I have to take care of it somehow. For now I plan on unlumping the file that grew too much and writing to it on the disk, then pulling the whole thing back together at the end. However I'm considering doing a fragmentation system like an actual hard drive uses but that will take some changes to all the read/write/seek functions.

Once I have file writing put in the code with the unlumping I'll probably take it to a different direction.

The .RPG file format is quite limited in the way it works (which I understand as James has pulled serious strings to get QBasic to do this stuff) and I was thinking of something more complicated. Right now in order to find the locations of all the files found inside you literally have to walk through the whole file and read them all out. I always invisioned a header at the beginning of the file that contained all that information for quick referencing.

I'm not sure how much I stressed it before but once I have something truly workable and not just hobbled together code I had planned on releasing the source code. I just don't see much reason to release source when it's not really up and running fully yet.

It's still quite the work in progress but it's getting done piece by piece. We'll see what the future brings us.

[TMC]

Yes, that is the method that the HamsterSpeak Decompiler and Importer use to access lumps inside hs/rpg files (hs files are lumped in the same way as rpg files), and it makes it soo much easier to work with, no mess, no problems with creating temp directories.

Well, I offer you good luck with your project, sounds quite useful. Why would you want a program comprised of 50 files can you can shrink it down to a handful?
_________________
"It is so great it is insanely great."

[Solsund]

I'm back.

Made some modifications to the TechDemo program and it's much better.

Now runs in a window and file it opens is no longer hardcoded.

Also can display tilesets in a file.

Needs a little testing as my computer can't hit a few of the
screen bit depths that it can handle.

More info about it in the readme file.

Things missing:
Exporting bitmaps - Intentionially left out due to lack of password handling.
Save last directory opened - Really easy but just didn't do.
Handle screen size/color depth changes - Still working on it.
Fullscreen/Windowing mode - Will have it changing back and forth.

Enjoy.

http://gameguru.freeservers.com/techdemo/index.html