Author Topic: HowardC, Lazarus, Virtual Dirs, stuff (Read 4232 times)

SirPoonga · « **on:** February 27, 2003, 04:25:30 pm »

Hey HC, are you not supporting lazarus now that you are developing dxLaz?

Will dxLaz use the same virtual directory structure?

I've been playing with that Virtual Directory Manager I created for you, suprised you haven't let it out. Need people to test it first? I'm sure people here would volunteer:)

If you aren't going to support lazarus anymroe and you don't mind I'll hand out the manager to people who want to try it out. I've actaully been using it to add rom dirs and virdirs to the dirs.ini file.

frankly, I don't plan on changing FEs from lazarus until mine is done. I'm sure other people are quite happy with lazarus as is and don't want to change. I'll still test your new version of whatever FE you make, just on my cabinet I finally got lazarus setup the way I want:) Glad your FE is so configurable:)

Howard_Casto · « **Reply #1 on:** February 27, 2003, 06:17:56 pm »

One of the main "features" of dxlaz is going to be the ability to be backwards compatable with previous versions of lazarus. There are obviously new options, but the old one's aren't going to change one bit.

So if your vdir manager is ready (again, sorry the format was going through growing pains when you started it.) Then by all means send it over. I'll include it with my helper apps.

Oh and I'm not "officially" ending support to lazarus, I just won't give support regarding errors that are caused by things that won't be in dxlaz. It's fruitless as a new version will be out VERY soon. So those of you with shockwave, real player and misc plugin errors just sit tight.... you won't have to deal with all that crap soon.

It's one of the main reasons I chose to go the directX route as the code is much cleaner and unified.

SirPoonga · « **Reply #2 on:** February 27, 2003, 06:30:47 pm »

Well, it's ready I think. How can I tell what version of laz I have? I don't remember if I upgraded to 4.5.

The tool could use beta testers to verify I didn't miss anything.

If someone wants to try it give me a PM.

Howard_Casto · « **Reply #3 on:** February 27, 2003, 06:49:56 pm »

well if your using 4.0 that should be enough... I don't think the vdirs changed between the beta....

SirPoonga · « **Reply #4 on:** February 27, 2003, 06:56:08 pm »

The manager I have now implements the filters in the virdir, not sure if there is anything new since then.

Lilwolf · « **Reply #5 on:** February 28, 2003, 10:02:08 am »

btw, what file format did you end up going with for the 3d models in dx? Are you parsing the files by hand?

I haven't been coding any on my 3d frontend (my cabinet isn't inside... so my insperation went downhill...). But I was planning on starting up again soon now that I'm working on a cocktail table.

But I will probably wait until the next version anyway. Why? I have found ways to get rid of all the nice features in JFront using different mame installs and different controller setups. So I can use anyones frontend... But as soon as I finished that... I decided to write a 3d frontend that will work well on a cocktail table... So I might start up again.

)p( · « **Reply #6 on:** February 28, 2003, 11:32:51 am »

Quote from: Lilwolf on February 28, 2003, 10:02:08 am

btw, what file format did you end up going with for the 3d models in dx? Are you parsing the files by hand?

I haven't been coding any on my 3d frontend (my cabinet isn't inside... so my insperation went downhill...). But I was planning on starting up again soon now that I'm working on a cocktail table.

But I will probably wait until the next version anyway. Why? I have found ways to get rid of all the nice features in JFront using different mame installs and different controller setups. So I can use anyones frontend... But as soon as I finished that... I decided to write a 3d frontend that will work well on a cocktail table... So I might start up again.

We decided on the .x format contained in a zip file with the required texturtes for each model. we choose this format because we can very easily export to it and most 3d engines can parse it directly or should be able to make a parser because it is well documented.

What kind of cocktail support in an fe are you looking for?

peter

SirPoonga · « **Reply #7 on:** February 28, 2003, 11:34:35 am »

now, just to find documentation on the .x format...

at least I can't find anything on how to use it in opengl

)p( · « **Reply #8 on:** February 28, 2003, 11:43:37 am »

Quote from: SirPoonga on February 28, 2003, 11:34:35 am

now, just to find documentation on the .x format...

did you do a search? i hope this will work out because it seems to be one of the only formats that works really well...

peter

SirPoonga · « **Reply #9 on:** February 28, 2003, 11:47:47 am »

I'm just wondering why that format, it doesn;t seem widely used, like 3ds.

)p( · « **Reply #10 on:** February 28, 2003, 11:54:38 am »

Quote from: SirPoonga on February 28, 2003, 11:47:47 am

I'm just wondering why that format, it doesn;t seem widely used, like 3ds.

3ds gave all kinds of problems while exporting especially the more complex models and the transparcencies

peter

SirPoonga · « **Reply #11 on:** February 28, 2003, 12:17:16 pm »

I suppose Hc has to answer this but again, why .x? It isn't used much. ASE, Quake3 models, others are much more widely used and there are tons of infomation on those formats out there.

Howard_Casto · « **Reply #12 on:** February 28, 2003, 01:29:21 pm »

Simply put, I couldn't find any examples of how to import quake models into directx. Or any other model format for that matter. Plus we have to use the most modern of the quake3 formats to handle shaders and transparencies, and I believe it has limitations. If anyone can find a format that has instructions on how to view it in directx then I'm all for it as even x files have to be manually parsed into the engine.

But be leery of game file formats... believe it or not many of our models have more complex shaders, larger texture files, and more polys than your average game model.

SirPoonga · « **Reply #13 on:** February 28, 2003, 02:32:11 pm »

Here's a tutorial that loos good. Hehe, in c++ HC, you'll loveit.
http://www.andypike.com/tutorials/directx8/010.asp

It is possible to load quake 2 models
http://hometown.aol.com/billybop7/

I wouldn't go with quake models unless you want animation, that file format was made for animation.

Howard_Casto · « **Reply #14 on:** February 28, 2003, 02:34:12 pm »

3ds is not an option btw... it's even more clunky than the x format and won't export properly from 3dsmax. (Texture mapping gets corrupted as does the object orientations)

What we really need to do is figure out how to read w3d files into directx... then a conversion wouldn't be needed and the textures would be iniside the file itself....

Howard_Casto · « **Reply #15 on:** February 28, 2003, 02:37:50 pm »

I've seen those tutorials and they really don't help. As I said, 3ds is out and quake2 won't do as it doesn't support transparencies. There has to be some universal format out there besides 3ds.

)p( · « **Reply #16 on:** February 28, 2003, 02:48:28 pm »

Quote from: Howard_Casto on February 28, 2003, 01:29:21 pm

But be leery of game file formats... believe it or not many of our models have more complex shaders, larger texture files, and more polys than your average game model.

yeah that is certainly true...the models are between 2000 and 6000 polys each...
a while back someone loaded the battle zone model into the quake engine and he had to split it into 4 parts...

peter

SirPoonga · « **Reply #17 on:** February 28, 2003, 02:56:52 pm »

I guess I am suprised if you can;t find info on directx supporting something like ase or pbj either:) But those are old school formats.

Lilwolf · « **Reply #18 on:** March 04, 2003, 03:45:14 pm »

btw, what is the .x format?

searching for it sucks (since google changes it to just x. so every webpage with a letter x and 3d and fileformat...)

I would love to take a look at it and see if I can parse it.

SirPoonga · « **Reply #19 on:** March 04, 2003, 03:53:53 pm »

search for directx file format

Lilwolf · « **Reply #20 on:** March 04, 2003, 03:58:45 pm »

Also, where are these files? I checked on 3darcade on mameworld and checked a few files to see if any had an .x file in them... but I found max files only.

Hoping for an example.

Lilwolf · « **Reply #21 on:** March 04, 2003, 04:08:16 pm »

And thanks for the quick reply

)p( · « **Reply #22 on:** March 04, 2003, 04:53:53 pm »

Quote from: Lilwolf on March 04, 2003, 03:58:45 pm

Also, where are these files? I checked on 3darcade on mameworld and checked a few files to see if any had an .x file in them... but I found max files only.

Hoping for an example.

there are not any .x files there yet...
As i said we are considering using that format...or better hc is still toying around with formats and stuff...

peter

Howard_Casto · « **Reply #23 on:** March 04, 2003, 05:12:24 pm »

Peter does have a copy of a MsPacman cab he converted for me if you want to play around with it.

Non encrypted x files are farily easy to work with as it's a written set of coordinates and paths to the textures (or alternatively material data). In theory it could be loaded into any program if you knew what you were doing.

)p( · « **Reply #24 on:** March 04, 2003, 05:32:49 pm »

Quote from: Howard_Casto on March 04, 2003, 05:12:24 pm

Peter does have a copy of a MsPacman cab he converted for me if you want to play around with it.

Non encrypted x files are farily easy to work with as it's a written set of coordinates and paths to the textures (or alternatively material data). In theory it could be loaded into any program if you knew what you were doing.

I allready looked a bit around for that one on my hd to email it to the wolfman...could not find it...will take another look tomorrow or just export a new one and email that...now it is sleeping time..over out...

peter

Lilwolf · « **Reply #25 on:** March 04, 2003, 06:21:46 pm »

Thanks! I would love to get it!

I looked at the file format. It seems REALLY easy! Cool!

Hopefully I will get a chance to parse throught one soon : )

Howard_Casto · « **Reply #26 on:** March 04, 2003, 06:53:58 pm »

Something of note: The main problem I have with the x format is the fact that the texture files are just thrown out there. I'm looking into methods which would encrypt the image data into the file itself, so stay tuned on that one. That way we can also encrypt the data so people's models aren't stolen and used in other projects illegaly.

As writing raw data is farily easy in any language, I'll probably make a "x" to "xCab" converter utility. That way we can have our own custom format!

Lilwolf · « **Reply #27 on:** March 04, 2003, 07:18:50 pm »

The trouble with that is then you can't use the image using standard api methods.

In java, if I want to load an image it's a few lines of code. For me to create an image from a byte stream.. is...well... I think a TON more -> a bit more. The TON more is if it's in a codex, if it's a raw byte stream bitmap, then it's pretty easy (I think).

I will take a look and see what it will take. But all in all, we can change some header/tags around and nobody will be able to steal them anyway.

But imbedding the image in there makes the file unreadable.. and at that point you might as well go to a binary type format.

How about a misnamed zip file with changed tagnames in the .x file. I don't think anyone would figure it out...

Or how about a password protected zip file which is all standard. So people who want to use them, we can tell the password to.. Only trouble here would be that any project thats opensource would have the password in it.

Lilwolf · « **Reply #28 on:** March 04, 2003, 07:27:15 pm »

btw, having the images in the file adds only 3 lines of code in java. I would only need to know what file type they are in advance. Not a big deal at all.

So if the file has something like

template image {
<uuid>
DWORD 4358<cr>
....4358bytesofimages<cr>
}

or whatever
or something. Some images might be reused in more then one location. So a reference should be added (if we care... I don't really... it will just make the file smaller).

Howard_Casto · « **Reply #29 on:** March 04, 2003, 07:34:32 pm »

Let me explain what I mean... I don't mean make the image data hidden inside the file. I mean "printing" the image data at the bottom of the x file. As anything past the end tag is generally ignored by dx anyway it would be just fine. Then you simply read the images into memory, save them to a file and load them that way, making sure to kill them as you exit the model. There would be a "key" inside the image data itself that you would have to know so you can properly re-assemble the images. Or alternatively there could be an x file and a seperate file in each zip, with the second file being the images.

There is a reason I want to do it this way..... without some legitimate hassle involved in accessing the images, any lacky with mspaint could make their own "model" and claim credit for it. This would both make a slew of ugly model hacks surface, and have legal issues.

Some type of encryption must be implemented. I am open ot ideas however.

Lilwolf · « **Reply #30 on:** March 05, 2003, 09:32:02 am »

I'm ok with anything that way. Good idea putting it at the end (because then the file itself can be read by other applications for testing).

but if only care about casual hackers... I like the idea of sending a password encrypted zip file. Then have the password something to do with the file name maybe...

but if we do this, then adding the image to the file doesn't make any sense... since it will already be encrypted.

Then we can give free reign to download the encyrpted zip files that will work with any project that has asked for how to generate the password... (like some play on the name of the zip file...)

Also, then we can have it work (in our FE's/apps) without the 'official' password encoding for testing, So a few of the models can be given out in unencoded format as demenstrations/examples for others to follow. And people trying to create on can test them in a FE/app without worrying about how to password their own file.

)p( · « **Reply #31 on:** March 05, 2003, 09:57:25 am »

yeah to have at least the ability to offer both encrypted and unencrypted versions gives the most flexibility.

by the way check your email

Lilwolf · « **Reply #32 on:** March 05, 2003, 10:57:21 am »

btw, my email server was !@# up last night. I'm not sure if I lost emails or if I will get them resent.

But if you have a sec, resend it.

Thanks!

)p( · « **Reply #33 on:** March 05, 2003, 11:06:40 am »

Quote from: Lilwolf on March 05, 2003, 10:57:21 am

btw, my email server was !@# up last night. I'm not sure if I lost emails or if I will get them resent.

But if you have a sec, resend it.

Thanks!

ok ;-)

peter

Howard_Casto · « **Reply #34 on:** March 05, 2003, 01:16:31 pm »

Putting the images in one or possibly two files is mostly a tidiness thing. Many of my models have upwards of 30 texture files, and even in a zip file it could get quite untidy to keep track of them all during conversion.

Lilwolf · « **Reply #35 on:** March 05, 2003, 04:25:10 pm »

I thought keeping them all in one zip file would make things easier to deal with. But it won't make a huge difference to me either way.

The main advantage I can see is that if someone doesn't care about encrypting their own, they don't need a tool and it will work with existing frontends without change.

And if you do care about it, the password encryption for the zip file will probably be much safer.


Main	Restorations	Software	Audio/Jukebox/MP3	Everything Else	Buy/Sell/Trade
Project Announcements	Monitor/Video	GroovyMAME	Merit/JVL Touchscreen	Meet Up	Retail Vendors
Driving & Racing	Woodworking	Software Support Forums	Consoles	Project Arcade	Reviews
Automated Projects	Artwork	Frontend Support Forums	Pinball	Forum Discussion	Old Boards
Raspberry Pi & Dev Board	controls.dat	Linux	Miscellaneous Arcade	Wiki Discussion	Old Archives
Lightguns	Arcade1Up	Try the site in https mode		Site News


Unread posts \| New Replies \| Recent posts \| Rules \| Chatroom \| Wiki \| File Repository \| RSS \| Submit news