Zelda64 Actor Viewer status thread

[Enzo Dragon]

Enzo Dragon: Yep, that's it. I didn't find it, actually, a guy named EFX did: it's just being rendered in my viewer.

It'd be pretty sweet if you got textures working in that thing.

Are the numbers you enter the actor data? Could I, in theory, use a GS code to switch in that model with another? That is, is that number in the text box relevant at all in the context of a gameshark?

 

[Danny]

Nice progress cooliscool

When did you start coding?

 

[cooliscool]

This program, or in general?

Overall, I've been coding on and off since I was pretty young, about 9 years old with QBasic, later moving to scripting/markup languages such as HTML, and even later C and derivatives. Never like C's (and derivatives) syntax, but always loved BASIC as a whole, so I work with it these days. As to why I've never released a big application, I've never seen a market that was really unsaturated or something I really *wanted* to tackle.

As for the program, I started not long ago (about a week or two before the start of this thread).

Slougi: As a user of Linux (and free/open source software as a whole), I'd consider you the first to accept Mono!

Enzo Dragon: No, that data relates in no way to actor group/number/variable. They are so dubbed "entry points", which are the beginning of display lists in the file.

 

[Enzo Dragon]

Thanks. Any idea where I can find that information?

 

[Cyberman]

Sorry to go offtopic, but OpenGL was stripped out of Vista? Is it supported hardware-wise, or is it just emulated with DX?

If it's seriously out, I'm going to be rethinking my next OS of choice

OpenGL is emulated through directX there is NO direct hardware support for OpenGL what-so-ever. They specifically said "You cannot write ANY drivers in Vista for OpenGL" MS intends to write all the drivers for DirectX it appears as well. (Just like they wrote the wonderful drivers for USB on my last Mother board... which didn't work at all.)

I doubt they will 'rethink' there position. It's not the death nell for OpenGL but it may make it very unconvincing to those in power to use OpenGL as an API for any project that will be run on Vista. What's the point? To be honest SGI ... ahem screwed things up since OpenGL was there baby. Of course Steve Balmer FIXED SGI, and that might be what the problem was. (Steve Balmer is the current CEO of MS and was CEO of SGI a while back he tried to convert SGI into a PC platform company, with disasterous results needless to say he was... booted out.)

OpenGL's wide use was primarily in games, with the exit of true OpenGL support in any Microsoft Platform, IE the PC world. It's unlikely it will continue to be a happy camp. However there is a big problem in the PC world, as the PC is becoming virtual. Many new platforms are becoming prevelant and this may be the death nell of windows as it use to be. IE every PC running Windows. Vista although promises a lot is being looked at more dubiously after the XP fiasco.

As for the subject of this thread. Cool-is-cool you don't have texture support? I thought you did! Ick. my bad. Have you found the textures even? I'm surprised the N64 could work as well as it did with a freaking cartridge. Ahem

Cyb

 

[ShizZy]

 

[Slougi]

Slougi: As a user of Linux (and free/open source software as a whole), I'd consider you the first to accept Mono!

Oh, I do accept it I just don't think that mono being available makes .NET a standard application platform.

Anyway, I'm gonna stop hijacking your thread now, sorry about that.

 

[Garstyciuks]

OpenGL will be available in vista, but its performance will be a lot slower. Here it contains more information about it.

Though I don't think that I will move to vista, some Linux distributions look nice

 

[Cyberman]

Eli asked about OpenGL, Direct Draw, and WPF, and how they work with Desktop composition...
OpenGL can go through one of three paths in Windows Vista depending on how your computer is configured.

1. MSOGL - this is an implementation of OpenGL 1.4 that uses Direct3D under the covers to hardware accellerate the application.
2. Legacy ICD's - These are the ICD's that are available today for use on Windows XP. These will continue to work on Windows Vista, but will disable the DWM when they are loaded in to the process of the application that's using OpenGL. The reason for this is that Legacy ICD's operate directly on the GPU without going through Windows at all, and we have no way of redirecting application's output in a stable, predictable manner.
3. Windows Vista ICD's - this is a new path for 3rd party ICD's introduced for Windows Vista that will work in a way that is compatible with desktop composition. Essentially allowing direct access to the GPU for hardware accellaration, but then having the final surface that appears to be the front buffer to the application actually be a shared surface that gets composed by the DWM

MSOGL is only 1.4, there is a reason for this, if you don't know MS currently only supports 1.2 by default. (This is no joke) This is what came with windows 95 and WinNT (now known as 2000 and XP they ARE win NT vista is another version of windows NT (64bit) its not NEW). The current version of OpenGL is 1.5 and it is moving to 2.0. Now let me think this through here... as you can see they aren't supporting it. 1.4 is being supported because most games at the time of Vista supported 1.4 features and extensions. Any of the new extensions and features obviously they do not want to support (because that would be an issue with direct X). #3 looks like they are allowing people to write ICD's ... but read it VERY carefully read #2 as well.

Back to the fun stuff ... Cool-is-cool how are you finding the models? Are you using the library function calls to find them? By the way what do you plan to do with this tool in the long run?

Cyb

 

[blueshogun96]

Quick question, are you using vertex arrays or VBOs?

 

[Danny]

This program, or in general?

Overall, I've been coding on and off since I was pretty young, about 9 years old with QBasic, later moving to scripting/markup languages such as HTML, and even later C and derivatives. Never like C's (and derivatives) syntax, but always loved BASIC as a whole, so I work with it these days. As to why I've never released a big application, I've never seen a market that was really unsaturated or something I really *wanted* to tackle.

Nice work, keep it up, im impressed

 

[cooliscool]

Quick question, are you using vertex arrays or VBOs?

Neither. Store in an ArrayList, then load into display lists.

Cyberman: Texture support is currently partially supported in the latest build, only a few transformation issues to fix up. It also now supports full dumping of all textures in the actor data to separate files. Parsing model data... my program works sort of like an N64 emu GPU plugin: interpreting F3DEX2 microcode commands and decoding them.

 

[ShizZy]

Is there actually a model format? Or do you just rip the display lists from the game and decode them?

 

[cooliscool]

Technically there's a format (F3DEX2 being the main part, with other tiny factors such as banks being specific to the Zeldas), but even still it's essentially just ripping the display lists and interpreting them. As I said before, while the program's code is all mine, I was not alone in deciphering the data. _Demo_ and MNGoldenEagle helped make the task a lot easier.

When I release it (which should be no longer than the next couple of days), I'll include the source code.

 

[Cyberman]

Cyberman: Texture support is currently partially supported in the latest build, only a few transformation issues to fix up. It also now supports full dumping of all textures in the actor data to separate files. Parsing model data... my program works sort of like an N64 emu GPU plugin: interpreting F3DEX2 microcode commands and decoding them.

I kind of thought that is what you were doing.
Knowing how Rice's plugin works with textures. There are some things I've been trying to resolve:

1. Broken up textures (IE one that is actually loaded in chunks of 2k/4k), these are a bit anoying as they technically are one texture but Rice's plugin sees them as multiple. The only way I can think to resolve this is assume if they have one dimension the same (IE they are all same width) and are applied to the same screen object ... then.
2. You discern between seperate screen objects (IE leech from the ROM the individual models) how? That is the key to fixing the issue with splintered textures with Rice's texture dumping program.
3. By being more discerning about texture use eliminate nuisance texture dumping (Like in Castlevania every time it writes text to the screen it creates 300k worth of textures).

In the end this will:

1. Reduce the number of textures (significantly)
2. Make it easier to make hirez textures, and make them more consistant.
3. Remove nusance textures (font texture data is not confused with actual text).

So actually you might be helping out lots of people you just didn't know it yet

Oh have you found anything about the animation information?

Cyb

 

[Enzo Dragon]

Doesn't this viewer only work with Ocarina of Time, though, Cyb? If that's the case, I figure that trying to apply his approach into a video plugin might be a little bit more tricky than you describe.

 

[cooliscool]

Ocarina of Time, Majora's Mask, and any other F3DEX2 game, actually.

Cyberman: Haven't even began touching the animation format.. all we know about it is that limbs are separated and artificially linked by the game at load, making objects with extensive animation load all at one place in my viewer.

 

[cooliscool]

Just noticed you had a question in your post, Cyberman. Sorry about that.

I discern between different models by so called "entry points," which define the start of a display list. An entry point is found by seeking the word "E7000000", and keeping that location in an array. Contained after the entry point information are all the rendering information (using F3DEX2 commands) I need to process. The End DL command in F3DEX2 is the byte "DF".

The user can then select from those locations, and each is a different model.
What I really want to do next is work on the bone format..

The basic flow is like this:

seek to entry point->search for specific commands->process data as required by the found command->if found command is ever "DF", end operation->render to screen.

There's of course the option of rendering all display lists in one area in the viewer, too. I've attached some (yes, textured!) examples.

 

[cooliscool]

Haha.

 

[blueshogun96]

lol, you were just waiting day and night for that to happen weren't you? XD