I'll Swizzle Your Face

I've been quite aware that my GIM de-swizzling has been pretty busted for a while now. I totally brute-forced it by looking at my raw RGBA pixel output and re-arranging pixel chunks based on bit depth conditions and all of this other crap, having no idea what in the hell was actually going on with the data. So I decided it was time to actually make it work right across the board. I figured this is a problem that had been solved 100 times over, so I went digging into the community-maintained pspdev SDK and its documentation, and what did I find? Swizzling (and de-swizzling) routines that were completely broken across varying image bit depths.

The way the data is arranged is actually pretty simple, and totally independent of pixel size or image dimensions. The GPU apparently likes to read data in 16x8 blocks, which means 16x8 bytes, regardless of the image is 4bpp, 8bpp, 32bpp, or whatever. So I sat down and wrote my own damn de-swizzling routine that works no matter what the image format, and even accounts for the rare case that the image pitch doesn't align to 16 (this is somewhat special-cased in GIM files as well, as their pixel data will be padded out).

static BYTE *Image_GIM_Deswizzle(gimTexHdr_t *texHdr,
				gimPixHdr_t *pixHdr, BYTE *buf)
{
	int width = pixHdr->width;
	int height = pixHdr->height;
	int imgStride = (pixHdr->colorDepth <= 4) ?
		width/2 : width*(pixHdr->colorDepth/8);
	int imgSize = imgStride*height;
	BYTE *dstBuf = (BYTE *)malloc(imgSize);
	/*
	swizzled images do not have to align to block sizes
	(e.g. being divisible by 16 in byte stride). images
	that fail to align actually have "dead" space in
	them in order to keep the pixel data block aligned,
	so we must iterate up to the given data size to
	ensure we grab that data properly.
	*/
	int realImgSize = pixHdr->partSizeA-sizeof(gimPixHdr_t);
	if (imgSize > realImgSize)
	{ //fallback, since i'm paranoid, should not happen.
		realImgSize = imgSize;
	}
	int dstX = 0;
	int dstY = 0;
	for (int i = 0; i < realImgSize; i += (16*8))
	{
		int baseX = dstX;
		int baseY = dstY;
		for (int j = 0; j < (16*8); j++)
		{
			if (dstX >= imgStride)
			{
				continue;
			}
			//index values here could be swapped
			//to swizzle instead of deswizzle
			dstBuf[dstX + dstY*imgStride] =
				(i+j < realImgSize) ? buf[i+j] : 0;

			dstX++;
			if (dstX >= baseX+16)
			{
				dstX = baseX;
				dstY++;
			}
		}
		dstX = baseX+16;
		dstY = baseY;
		if (dstX >= imgStride)
		{
			dstX = 0;
			dstY += 8;
		}
	}

	return dstBuf;
}

I realize there is less than a 0.0001% chance of anyone ever finding this useful in any way, but what the hell. Oh, and "buf" is the raw pixel buffer portion of the GIM, it hasn't been processed or converted in any way at this stage. You also totally don't need to maintain separate destination indices, or even have a second for loop (in fact this could be done all awesomely and with purely contiguous reads) but I was too lazy to clean them up after I nailed the pattern down. That's just the way it goes, my brain works in highly obfuscated and abstract ways until it finishes solving problems.

Comments

21 comments in total.
Post a comment

#21

Rich Whitehouse

February 10, 2010 at 7:59 am (CST)
Oh man, you posted that :P right as I was posting my :P article. Sorry, I wasn't directing it at you! :)

But yeah, I've been continuing to crank out models and stuff for my project despite feeling relatively horrible. Fortunately, a lot of the stuff that needs doing now doesn't require a great deal of focus, so I'm getting by. In fact, the rest of the project is pretty much all just content and refinement. No more complicated stuff left on the plate.

As for the rest of what you've said, I think it deserves a more thought-out reply, and I'm on the verge of passing out here. I'll formulate some thoughts on it when I wake up to(day)morrow.


#20

ukurereh

February 10, 2010 at 6:59 am (CST)
Hey Rich, hang in there. Not sure what else to say. Uh, get some pills and watch more porn? Or maybe you can multitask that somehow if you're anxious to get the iPhone stuff done.

I looked at a couple Quake 3 menu files, and I guess I get what you're saying. Definitely works for placing blocks of stuff around the screen -- would you also be using this for inline/text-level formatting? And how about separating presentation from content (if it makes sense to do that here)?

Actually, I'm interested in the 3D stuff, too (good for mental exercise, if nothing else). So, what's this about completely procedural 3D derived from an extremely simplified dataset? You mean something like prims? Second Life has a prim system, something I wasn't too fond of (though I guess I wasn't fond of Second Life in general). Could it be made as flexible as a 2D vector image format? Because that would be cool.

The 3D web you're thinking of, is it an overall 3D world like Second Life in which people make their own buildings (or whatever), or is it like Google's O3D where people create their own seperate worlds/applications? The latter makes more sense to me, since it's more World-Wide-Web like.

*Sigh*... "3D web" has been tried again and again yet hasn't caught on (as far as I see), despite all the valiant efforts at standardized 3D formats. Maybe what it really needs is some sort of killer app. What sort of killer app got the original World Wide Web off the ground? Whoops, maybe I shouldn't go there.

Anyway, don't sweat the response too much, since this is all just a "what-if" scenerio.

P.S. Almost forgot these questions, hope I'm not spamming you too badly. How does one make a good, extensible file format, and would you say XHTML/CSS is extensible or not? (Assuming I didn't miss you explaining it already :P)


#19

Rich Whitehouse

February 9, 2010 at 5:22 am (CST)
Apparently I already mentioned that AOL thing too. Something about it sounded really familiar in my head, so I used my own very convenient comment search functionality to check. Sorry, it's probably some mix of end-of-project psychosis, vicodin, and/or the other medications I'm currently on. I was diagnosed with diverticulitis, so they threw a bunch of pills at me. Who knows what the hell any of them do. Except the vicodin, it does great things. Although I just ran out, so now I kind of want to die again.

They also have no real idea why I have it (it's relatively rare in people under 40). My diet doesn't seem particularly conducive to it, being pretty decent in terms of fiber intake, though also not particularly high in it. I guess my ass-parts are just prone to breaking down and trying to kill me because they feel like it. I also have my theory about it being related partially to circulation and the fact that I've been spending over 95% of my waking hours on my ass typing line after horrible line of C code.

I also completely can't sleep because I failed to fall asleep before my last pill wore off and the gut pain is a bit much at the moment. This is a terrible situation. I guess I'll go watch porn.


#18

Rich Whitehouse

February 8, 2010 at 8:57 pm (CST)
Oh yeah, I remember actually playing with VB too for a little bit. I think it was even after I'd started on C++, although I can't really remember too clearly. I only used it for cheesy form applications, I remember one in particular was this terrible "AOL proggie" that could IM/e-mail spam and a bunch of other childish crap. :)

What would I do differently, huh? That's a small question with a pretty gigantic answer. I don't really want to type out another 20 paragraphs right now, though. First, it depends on if I were going to transition to 3D. I would really be inclined to package that into the system if I were developing a new set of global web standards today, because low-end hardware can handle it now, and cheap software rendering would be an option for the low-end (since what was displayed would be completely procedural and derived from an extremely simplified data set).

But I'll assume you're more interested in how I would have done those existing 2D standards differently to begin with. To be concise on that end, I think the end result would be a system that can produce content in a manner similar to flash (minus the massive overhead of all the unnecessary additional 2D transforms), with a hierarchical plain-text syntax similar to HTML but not based on encapsulation as a means of modifying the display of content. Off the top of my head, the closest thing I can think of is Quake 3's menu system, though it is in itself severely lacking, with its hardcoded functionality and generally over-complicated options.

The iPhone project is actually on its last stretch, I was working on it just as I noticed your message come in. I've been working on it pretty much non-stop, 10-16 hours a day 7 days a week, for...a while now. I mean, I've been working on it with reasonable consistency since even before I wrote that iPhone developer article, but my pace of development has been wobbling all over the place. At this rate, though, it should really be done by the end of the month. I just hope I can keep it up without dying.

My sanity and coherence takes an extremely steep dive near the end of these massive, way-too-ambitious solo projects (though this one hasn't been entirely solo, since I've hired contractors for nearly all of the map/character model content), and I've been feeling the sharp teeth of madness gnawing away at my brain for some time now. I guess it's naturally what happens when you force yourself to work brutal hours and cease all of your social/recreational activities completely in the name of accomplishing a single daunting far-away objective that you can only claw your way toward bit by bit with your metaphorically gnarled and bloody finger tips. And on that note, back to work!


#17

ukurereh

February 8, 2010 at 8:11 pm (CST)
Blah, been busy with school. Funny how you learned from bytecode (gawd D:) and worked your way up, while spoiled me started from Visual Basic and worked my way down.

I keep reading what you typed, but it's clear as mud to me, so I'll try a different approach... If you were put in charge of redoing this whole XHTML/CSS/DOM/JavaStuff, how would you do it differently, and how might it look?

P.S. How's the iPhone stuff going? I know you can't say too much about it until you're done, but your "Interview with the iPhone Developer" post was an interesting read.


#16

Rich Whitehouse

January 19, 2010 at 3:48 am (CST)
Referring to something as parametric in the computing world typically means that its desired state can be described in any form of existence (subject to the parameters of "existence", such as, say, time) by a fixed set of values. A good reference would be a "parametric particle system" versus, say, a "physics-driven particle system" (also of note that this is probably where the misconception of use came from, since methods used to describe particles in motion can correctly be described as parametric). It's just one of those things that I've observed in common use and started throwing around. Like the word "lerp". Someone just said "I don't know what lerp means" to me today, which caused me to actually pause and think about the vocabulary of nonsense words/contexts that I frequently adhere to thanks to my practical experience in the field of computer graphics.

However, you can define a physics-driven particle system as parametric too, if you stretch the definition to be less subject to when/how the values that describe a system are defined. As with many such terms, the use of "parametric" to describe systems is more "common sense"-related than it is technical. :)

I'd say HTML is by definition a parametric language, although it lacks any functionality that might have it run contrary to that (things like independent movement of objects are typically done with JavaScript, or something else even more far-removed from HTML itself). As such, I didn't mean to say that HTML wasn't parametric when I proposed the alternative. I was just describing the more ideal system, and being parametric was part of it, but the actual difference between the two is the concept of common data reference. HTML has plenty of data reference, but on the whole does not make very effective use of it (I'd say it rather only makes use of it where it's absolutely forced to).

GMO's actually still lack the ability to reference different vertex data layouts (anything non-interleaved). You could shove the data in there like that, but it'd be beyond the scope of the format. It's also beyond the scope of the platform the format is made for, which is why it isn't there. But it's one of those things that is totally necessary for any non-platform-biased universal format.

There are up sides and down sides to supporting everything on the face of the earth, however. In accommodating so many different potential data storage formats, it also puts a burden on things from the implementation side. At that point, for the format to be easy to use, you need a library that you can call to and say "Give me the vertex data in this format" and it just goes and fetches and converts as necessary before handing back to the user.

This has become necessary for COLLADA implementations too, in order for it to maintain common use by developers in their assorted technologies. There are so many indirect references between data types that writing a COLLADA implementation without a translation layer, from scratch, would be a real effort. It's quite a contrast from being able to just load a binary in memory and know which data is where and how it's stored from a very fixed list of possibilities. Of course, a library seems like a good solution, but has its downsides too (it hinders cross-platform/language development substantially).

So, a good global format is usually about walking that line, and providing good tools to export that data in ways that the user wants. As with GMO's chunk format, unknown chunks can simply be ignored, and the user only needs to implement handling for data they care about on the platform(s) they care about.

The RDM format is mine, I came up with it like 5-10 years ago when relatively inexperienced. However, despite my inexperience, I knew enough to go with a GMO-style chunk system, which has allowed the format to expand endlessly without breaking my older games and tools. As far as what it supports, pretty much everything in the world at this point, but of course, you only implement what you need. I've done quite a few implementations of parsers over the years, though the one in the R-Cube engine is by far the most complete/horrifying. It's really not the ideal universal format for others, simply because it's way too complex.

For any engine that doesn't actually require flexible data storage, I would just use a fixed-layout binary format. Although, interestingly enough, I haven't run into that need yet. My own main engine is cross-platform for quite a few platforms, so it handles translating data on load from RDM's into whatever the native expectation is. Though for final shipping cases, each platform has its own copies of models which have their data all natively stored in the most ideal manner, so no translation on load is necessary. Going through the trouble of having the data native is probably a total difference of like 200ms in load time for anything I've ever worked on, but hey, why not.

The GMO texture animation chunk, I have no idea. I've not investigated the data at all, and I can't remember what I saw in it when I first came across it that prompted me to classify it as a texture animation chunk. Seems like there were some string references in it, or maybe I just noticed it referencing the animation texture by index. I really have no idea. Once the project I'm working on right now is done, I might go back and look at it again. I'm forcing GMO's off my plate for now, though.

Oh, are you a Gackt fan? I'm glad to hear it. Every man should aspire to be Gackt-like in whatever he does. But anyway, that bit I was referring to was in the "Knives" section:

"When I was 9 or 10 years old, my hobby was writing computer programs. Personal computers had just come out, and using machine language, I wrote a program. I remember that my computers were a 6001 Mac II, a 8001 Mac II, and then a 9801 FR…

Though I wrote a really awesome program, I didn't do much with it. Though I was wondering what I was going to do with it, I still put everything I had into it. Floppy disks hadn't been invented yet. So all my programs were saved on a rectangular 30 cm personal tape recorder, which would go "piiii pirororo ppi" when you saved anything.

What's more, it was really irritating that even though I spent 3 hours working on a program and saved it, it would take up 50-60 minutes on a tape recorder. If I was in the middle of it and the tape was damaged, I would have to start the program all over from scratch. The tape would go "piiii pirororo ppi" and then "ERROR!" would appear. That happened many times, and I would yell, "It's not an error!"

I lost interest because of that. I wrote programs that could give an answer to a numerical formula, but I could calculate the answers faster on my own. I started to think, "Do I gain any meaning out of writing these programs?""

It sounds a little bit strewn in Gackt's usual special kind of bullshit, although it's still awesome. I remember starting on the Commodore 64 when I was 8 or 9. I would type up pages of binary at the prompt using command keys (because I lacked an actual assembler) and save it to disk. I started that once I saw it was way too slow to poke pixels to render/clear in BASIC. Then my parents got a x86 machine, and I got a book that came with a x86 C++ compiler and I was set for life. Sometimes, though, I still want to go back and waste hours on end writing C64 programs (although in correct 6502 assembly, I'd rather kill myself than go back to typing in bytecode).


#15

ukurereh

January 19, 2010 at 2:32 am (CST)
Whoops, I meant "it's always fun to read your stuff." Now feel free to ignore any other typos I may have :P


#14

ukurereh

January 19, 2010 at 2:30 am (CST)
Hey Rich, it's always to read your stuff, even if I don't always understand what you're saying @_@

So you said HTML would be easier as a parametric system instead of using tag encapsulation. First off, when you say "parametric," do you mean "an object in a CAD model that can be modified simply by changing the parameters used to create it (e.g., dimensions, design constraints)?" If so, then that's the first time I've ever seen "parametric" used as a noun, yikes. (Most interesting word/definition I've learned since "quaternion" :P)

But in HTML, don't a tag's attributes (plus its style attribute) act like parameters? And I don't understand specifically (or even generally) what makes HTML's tag encapsulation more difficult to extend than something like 3DS's chunk system. Maybe it doesn't even make sense to compare tags to chunks at all, I don't know.

[now for 3D stuff...] Actually, the XG format from the PS2 version of Gitaroo Man pretty similar to (and about as flexible as) the GMO format (and some of your GMO info helped me out with it, so thanks!). Of course now it's yet another abandoned 3D format, only having been used elsewhere in a few board/card game sims and a bus-driving game. I don't know if anyone even made use of its particle system -_-

So, about your RDM format... is it yours, or did you borrow it from somewhere else? I tried googling but didn't find anything descriptive. What's the file format like, and what kind of stuff does it support (and is there anything from the GMO format it doesn't support)? I figure it can't be too bad if you're using it :D

About that GMO texture animation chunk... How is it determining which region to grab from the source texture? I'd expect it to be in pixel coordinates like the region for the target texture, but it's not. Or maybe offset in pixels, but it doesn't look like that, either. I see a big number like 9776 followed by a small number like 5 (always 5?)... what does that mean? I'm too lazy to investigate futher, especially if you've already figured it out anyway.

And lastly... your links page says Gackt did assembly programming and could compute stuff faster than a Mac. I skimmed through the translated autobiography but couldn't find anything about that... Please tell me, is that stuff true? Because if so, that would be totally rad.


#13

Rich Whitehouse

January 10, 2010 at 1:24 pm (CST)
Well, the blinking eyes and shining swords are two different things. The eyes are referencing different pixels in a single GIM, and things like scrolling/pulsing effects are done with materials. I did notice a chunk that I thought might give information on the offsets for the eyes texture (rather than being referenced by UV's, it seems possible that they are uploaded as a small rect over the corresponding texture page during runtime). I haven't looked into that and really have no plans to, though.


#12

NeoCloudstrife

January 9, 2010 at 7:01 pm (CST)
This really is probably a stupid question, and i don't a have a clue what i'm talking about, but I'll ask out of curiosity anyway. You see in dissidia how there are "animated" textures? (i.e blinking eyes, shining "ultima weapon" sword) I was just wondering if this is part of the GIM format(like, animated GIMs) or whether this is something dissidia does in the games actual code. I was just wondering because i wanted to ask if it was possible to implement animated texture viewing into Mesh2rdm. I've been experimenting with implementing new textures into GMO files, and it'd really help, if it were indeed possible. Again, sorry if I'm just being stupid, I really have no idea what I'm talking about.


Comment Pages:
[1] 2 3 ... Next

Post a comment

Name:


Enter :


Comment:

Stream Tags

Projects

Everything

Personal

Commentary

Indie

Technology

AVALANCHE

R-Cube Engine

Modding

Game Design

Commercial

iPhone

DickCam