XeNTaX

Posted: **Fri Sep 23, 2011 6:23 am**

Oh yeah, swizzle vs. twiddle. I've decided that swizzle should be used exclusively to refer to the process of swapping/re-ordering components of a fragment/pixel. The word swizzle is widely used to describe that process in the graphics world. Twiddle should be reserved for describing a byte-level and/or whole-fragment-level re-ordering/tiling of data. In other words, re-ordering things on a component-agnostic basis. The first time I personally saw twiddling used to describe tiling into GPU memory was in the Dreamcast SDK, though I'm sure it existed for quite some time before then. Many official docs since then have described a similar tiling process as swizzling, but I guess that's just how it goes when engineers are pulling words out of their asses to describe things which end up describing subtly different techniques in the same general area of work.

So there's that. I always try to stick to calling them appropriately, although sometimes I slip up in conversations when other people keep calling them the wrong thing.

Posted: **Fri Sep 23, 2011 6:28 am**

It's a good thing I still dual-boot with Windows, because apparently Noesis no longer works with Wine (I dual-boot with Ubuntu 11.04, latest Wine version installed through PPA). Which is odd, considering it used to work just fine in Wine.

Times like this I wonder why Noesis isn't multiplatform... oh well.

Posted: **Fri Sep 23, 2011 6:58 am**

Latest version still works just fine for me in whatever ancient version of darwine I've got on my osx partition. Reasons for not making non-Windows builds are numerous, including the fact that there's absolutely no reason it shouldn't run in wine (and has never failed on any version I've tried - it's very generic, runs on ancient versions of Windows, and no version of wine has any excuse to NOT run it), and the fact that it's just not worth the effort to maintain, when I'm already maintaining multiple API layers and native plugins.

Posted: **Fri Sep 23, 2011 7:10 am**

MrAdults wrote:Latest version still works just fine for me in whatever ancient version of darwine I've got on my osx partition. Reasons for not making non-Windows builds are numerous, including the fact that there's absolutely no reason it shouldn't run in wine (and has never failed on any version I've tried - it's very generic, runs on ancient versions of Windows, and no version of wine has any excuse to NOT run it), and the fact that it's just not worth the effort to maintain, when I'm already maintaining multiple API layers and native plugins.

Eh, that's fine, I'm mostly curious as to why Wine suddenly decided to stop cooperating with it. I do get some sort of output in terminal when trying to run it, so I was wondering if you had any idea what it means or whatever:

Code: Select all

philip@philip-Dell-DXP061:~$ wine '/home/philip/Noesis/noesisv358/Noesis.exe' 
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:shell:SetCurrentProcessExplicitAppUserModelID L"Casaroja.Noesis.1000": stub
philip@philip-Dell-DXP061:~$

I did once get a much more detailed output, but I forgot to report it earlier. Still hope this is of some use to you.

Posted: **Fri Sep 23, 2011 6:52 pm**

The contents of this post was deleted because of possible forum rules violation.

Posted: **Fri Sep 23, 2011 10:36 pm**

I managed to get a detailed debugging output of Noesis' crash under Wine, I hope this is of use to you, MrAdults: here ya go.

Posted: **Sat Sep 24, 2011 2:34 am**

Looks like a crash in __PyVerify_fd (Python library) based on the address. That function is Python-native and is just trying to validate a file handle. It's rather disgusting and makes assumptions about what the CRT is doing, and I'm sure Wine is doing something it doesn't expect. Arguably Wine should be doing what it expects, though, since the objective there should be to emulate the Microsoft CRT's faithfully.

Figures that the first thing to break Wine compatibility would be a thirdparty library that otherwise boasts cross-platform compatibility in its uncompiled state. If you want to avoid the crash you can just rename/delete NoesisPython.dll from your plugins folder, though of course that will mean you can't use Python scripts. Maybe I'll make the effort to find a Wine distribution that crashes it and see about recompiling Python to do something less terrible for validating file handles, since you (unlike 99% of my anonymous asshole users) went the extra mile to provide meaningful info on your crash.

Satoh: I may get around to looking at that eventually, though I honestly don't personally care.

I just looked at the TXY to give you a starting point and demonstrate how to handle tiled PS2 data. I tend to be helpful with people when they're actually making a demonstrable effort in figuring things out for themselves. (this is, again, unlike behaviors exhibited by 99% of my anonymous asshole users)

Posted: **Sat Sep 24, 2011 2:38 am**

Well in that case your work is much appreciated. As I said I wasn't asking, nor was I expecting.

I'll keep looking, eventually I'll get it, right? At least that's the idea...

Posted: **Sat Sep 24, 2011 6:28 pm**

Satoh wrote:Well in that case your work is much appreciated. As I said I wasn't asking, nor was I expecting.

I'll keep looking, eventually I'll get it, right? At least that's the idea...

That's usually how it goes. In the case of PS2 stuff, at least there's a lot of documentation on the hardware workings floating around the internet.

I uploaded a build with some Wine fixes last night. I compiled the CRT into the Python library which fixed the main crash with file handle validation. (since it was the Wine CRT implementation that was fucking it) Then I ran into another crash in 1.3.29 where something was fucking up when Python tried to create the stdout stream, so I made it handle that and write to null if that happens. Seems to only happen when you launch in a Wineskin debug shell, though, oddly enough.

I also couldn't even get the piece of shit to give me a module list (it kept running into an error in the very act of echoing it) so I couldn't easily determine the non-relative address of my own crashes on there. Things seem all around horribly broken in both 1.2.3 and 1.3.29 as compared to my old version of Darwine where shit actually just worked as expected straight away. Apparently they've never tried testing an app with a native implementation of Python in it, either. It crashes outright on initialization for the vanilla Python 3.2.1 binary, and I would imagine any version of Python containing the MSVC 2005 CRT hacks. (linking statically to the CRT's typically isn't done and is generally ill-advised and makes your binary significantly larger, but in this case it's the only way you'd miss this crash)

I would be tempted to fix some of these issues in Wine, if the fact that half of the development-related things I want to do in any given distribution of Linux also result in running into more blatantly fucking broken shit, and if you think Windows has dependency problems, you obviously have never tried create a universal Linux binary. And no, you stupid fucks, never distributing fucking binaries for anything isn't a good fucking solution for your problem there. Linux development for anyone that actually cares about trying to make something work is a slippery slope that leads to a cliff and at the bottom of the cliff is only despair and a new-found lack of faith in any kind of collective human endeavor not driven by direct material profit, where all of the fat lazy Linux nerds sit around stuffing cheetos in their faces and making excuses for how broken their software is, having already filled up on enough self-validation through their development efforts thus far to feel justified in sitting on their mountain of broken garbage and calling it a completely viable alternative to Windows.

(yeah, I've been having a lot of issues with Linux lately)

Posted: **Sun Sep 25, 2011 2:23 am**

MrAdults wrote:
Satoh wrote:Well in that case your work is much appreciated. As I said I wasn't asking, nor was I expecting.

I'll keep looking, eventually I'll get it, right? At least that's the idea...
That's usually how it goes. In the case of PS2 stuff, at least there's a lot of documentation on the hardware workings floating around the internet.

I uploaded a build with some Wine fixes last night. I compiled the CRT into the Python library which fixed the main crash with file handle validation. (since it was the Wine CRT implementation that was fucking it) Then I ran into another crash in 1.3.29 where something was fucking up when Python tried to create the stdout stream, so I made it handle that and write to null if that happens. Seems to only happen when you launch in a Wineskin debug shell, though, oddly enough.

I also couldn't even get the piece of shit to give me a module list (it kept running into an error in the very act of echoing it) so I couldn't easily determine the non-relative address of my own crashes on there. Things seem all around horribly broken in both 1.2.3 and 1.3.29 as compared to my old version of Darwine where shit actually just worked as expected straight away. Apparently they've never tried testing an app with a native implementation of Python in it, either. It crashes outright on initialization for the vanilla Python 3.2.1 binary, and I would imagine any version of Python containing the MSVC 2005 CRT hacks. (linking statically to the CRT's typically isn't done and is generally ill-advised and makes your binary significantly larger, but in this case it's the only way you'd miss this crash)

I would be tempted to fix some of these issues in Wine, if the fact that half of the development-related things I want to do in any given distribution of Linux also result in running into more blatantly fucking broken shit, and if you think Windows has dependency problems, you obviously have never tried create a universal Linux binary. And no, you stupid fucks, never distributing fucking binaries for anything isn't a good fucking solution for your problem there. Linux development for anyone that actually cares about trying to make something work is a slippery slope that leads to a cliff and at the bottom of the cliff is only despair and a new-found lack of faith in any kind of collective human endeavor not driven by direct material profit, where all of the fat lazy Linux nerds sit around stuffing cheetos in their faces and making excuses for how broken their software is, having already filled up on enough self-validation through their development efforts thus far to feel justified in sitting on their mountain of broken garbage and calling it a completely viable alternative to Windows.

(yeah, I've been having a lot of issues with Linux lately)

Eh, at least Noesis works again. And IMO, Linux wouldn't be suck a clusterfuck if people could just agree on standards for development. Instead, we get crap like GStreamer, PulseAudio, JACK, ALSA, OSS... and that's just sound architectures. Good thing Linux is very modular, else we wouldn't even have half-working distributions nowadays.

Posted: **Mon Sep 26, 2011 9:54 pm**

wow thats nuts, would have never figured any of that out. thats crazy that the palette is in one of the texture offsets O_O

I have to get around to writing up specs for the PXY format.. I think me and chrrox pretty much killed it, but I'm having problems with the bone ids.. they seem to work on some models, but not others, so sadly the weights are messed.

I also did a bone test last night in the emu and was shocked to findout that the game does not have any parenting what so ever O_O
if you move the root bone, normally the entire mesh moves with it. just as an example I showed how a model in max without parenting looks.. same as in the emu.. sucky

Posted: **Tue Sep 27, 2011 2:24 am**

Flattened skeletons are very common, particularly in the PSX-PS2 eras. No hierarchical transforms required at runtime. Lots of games still flatten the skeleton across specific hierarchies while retaining hierarchy where necessary for procedural joints too. The only real downside to doing it that way is that you may have less compressable data, but that doesn't matter anyway if you're just storing flat lists for every frame.

Posted: **Tue Sep 27, 2011 5:15 am**

could you have a look at xenosaga3's TXY they seem to be slightly different

C3kosmos00.rar

Posted: **Tue Sep 27, 2011 11:50 am**

MrAdults wrote:Flattened skeletons are very common, particularly in the PSX-PS2 eras. No hierarchical transforms required at runtime. Lots of games still flatten the skeleton across specific hierarchies while retaining hierarchy where necessary for procedural joints too. The only real downside to doing it that way is that you may have less compressable data, but that doesn't matter anyway if you're just storing flat lists for every frame.

Yeah it seems they developed thier own compression based on lzss that they used on the stage and animation files.

Posted: **Sat Oct 01, 2011 11:39 pm**

Please look at this archive, why not loading texture stored in .mtl ?

model here http://rghost.net/23849071

P.S. Support .fbx would be nice

XeNTaX

Spotlight: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis

Re: Señor Casaroja's Noesis