The Official Rant Thread

[JacksonCougar]

Well seeing as you left no message and she has no idea why you called you should try calling again.

[OwnZ joO]

Yeah definitely don't ask her out over a message, you would fuck it up most likely and sound stupid on top of it being lame already. If you call back again and get message tell her to call you back.

[DemonicSandwich]

My drill battery is dead. :/
I thought it was just the charger that was the problem but apparently the base melting was only a symptom.
All but 2 cells are internally shorted between the terminals. :/

[Aumaan Anubis]

Allowing my friend to "check out" my phone after talking to him about the prom rejection but potential date situation was probably a poor decision.

I'll just have to see how it works out.

[Aumaan Anubis]

LIFE IS A FUCKING CRAPSHOOT OF BULLSHIT.

[JacksonCougar]

What's the matter Aumaan?

[Grimdoomer]

Fucking halo 3 sids.

[xxpenguinxx]

Sterioscopic 3D monitors are coming out

I hate hearing 10 seconds of some overused meh song every time I try to contact someone by phone.

[troymac1ure]

I just don't like working with the Meta Editors... Memory hogs and hard to track issues.

EDIT: DAMN! Wasted my 400th post in the rant thread!

[DemonicSandwich]

My lamp is beginning to fail. The bulb is still in working condition but the lamp has begun to occasionally fail to start.

[XZodia]

Why are there kids playing halo 2, whose balls haven't dropped yet?

[JacksonCougar]

Reason: unknown.

[Grimdoomer]

[JacksonCougar]

[DemonicSandwich]

Oh wow, I actually lol'd.

[Grimdoomer]

It's like playing Mr.Potato head with their genitals.

[JacksonCougar]

It's been three days and I still have not been able to get my head around deswizzling. I just cannot fathom it. Also just looking at the raw bytes it appears that the way this bitmap is swizzled is slightly different from how some others are.

[troymac1ure]

I looked at it for quite a while (not understanding a bit of Entity's swizzle/deswizzle code) & tried to understand it, but still don't fully understand it.
It sounded to me like the way the nintendo did colors, in a 2x2 square with a bit to allow color palette 1 or 2 and then the remaining bits allow 1 of four colors within the palette.
It's not exactly the same as the NES, but I think the idea behind it is.
I assume that you are talking about H2 swizzling as I think it's developer based more than anything.

[JacksonCougar]

I'm not sure it's that exactly. It seems more like the bitmap is being arranged to be read by blocks in a linear fashion. But the blocks are not linear in form. And that's the part that confuses the hell out of me because I guess I have always been used to thinking of bitmaps as a linear byte[], not a a byte field (byte[height, width]). I think I finally clued into what entity is doing with the deswizzle method after the fourth day of letting the code simmer on the back-burner. Another thing that confuses the hell out of me is the blocks seem to be measured in pixels and not in bytes. Which seems just weird.

[Aumaan Anubis]

I am so lethargic today. I really want to do nothing.

[Call Me Alexx]

dickhead.

~XZ~ Thank you, Captain Obvious.

[Gary]

I am a fucking idiot. Can't remember the fucking simplest of shit for math. I deserve an F.

[Prey]

I just don't like working with the Meta Editors... Memory hogs and hard to track issues.

EDIT: DAMN! Wasted my 400th post in the rant thread!

The only thing you need to do is make sure you call dispose() on all the controls. Then it's up to the GC.

Another idea you could try is once the user has loaded one plugin, keep a reference to the controls so when the user loads a completely different plugin you can still use the same controls.

E.g.
case Reflexive:
// add reflexive panel, combobox ... here
Panel p = GetControl(typeof(Panel)) // might want to cache the typeof's
...

GetControl(Type type) {
Foreach ctrl in currentControls {
if (ctrl.gettype == type) {
currentControls.remove(ctrl)
return ctrl
}
}
return new {switch(type) typeof(Panel): new Panel() ... }
}

Or perhaps find a gui on the internet that uses less resources than the winforms does.

I'm not sure it's that exactly. It seems more like the bitmap is being arranged to be read by blocks in a linear fashion. But the blocks are not linear in form. And that's the part that confuses the hell out of me because I guess I have always been used to thinking of bitmaps as a linear byte[], not a a byte field (byte[height, width]). I think I finally clued into what entity is doing with the deswizzle method after the fourth day of letting the code simmer on the back-burner. Another thing that confuses the hell out of me is the blocks seem to be measured in pixels and not in bytes. Which seems just weird.

Swizzling is all about speed. Your right to think of textures as linear byte arrays, but this isn't good enough for a 3D game.

Heres a good diagram/explano:

This is an image as sequential: (each pixel is represented by 4bytes[8 bits per pixel so a8r8g8b8]), 4 pixels on each line.

0000 0000 0000 0000
1111 1111 1111 1111
2222 2222 2222 2222
3333 3333 3333 3333
4444 4444 4444 4444
5555 5555 5555 5555
6666 6666 6666 6666
7777 7777 7777 7777

Then the swizzled texture would look like this:

0000 2222 4444 6666
0000 2222 4444 6666
0000 2222 4444 6666
0000 2222 4444 6666
1111 3333 5555 7777
1111 3333 5555 7777
1111 3333 5555 7777
1111 3333 5555 7777

So why is this faster? Because normally for texturing, you need to read neighboring pixels instead of sequentially, since most of the time the texture is not drawn axis aligned, so you have to step in the Y direction and possibly even negative X dir. Plus for bilinear filtering you need to read the texels right and below the current one - with this texture order, it is more likely that those texels end up in the same cache line that was filled before.
In the above example, each line would fit into a single cache line, hence you could hold the whole top-left (and the bottom-left) 4x4 block of the original texture in two cache lines with the swizzled data, where you need 4 (8-) with the unswizzled approach.

If the data is stored in the original form then the correct pixel in a neighbouring row is quite a long way away. This can cause cache misses.

So basically an image is chopped up into blocks, whose size depends on the pixel format, and rearranged for speed. You can see this if you output the image with no swizzling, and output it for each stage in th swizzle.

[JacksonCougar]

I grasp the concept and the reason for it, but I failed for a long time to grasp the part about getting the offset using a masked int. Now I just have coders block and that has me treading water.

[Prey]

I grasp the concept and the reason for it, but I failed for a long time to grasp the part about getting the offset using a masked int. Now I just have coders block and that has me treading water.

offset? are you talking about the raw offset then also encodes which map the raw is in? The AND bit operation is just a way of masking out the bits you want: AND only returns a 1 if both its inputs are a 1, therefore your mask should only have 1's where you want to take data from:

e.g.

Code: Select all

number = 1100 1010
mask =   0011 1111
result = 0000 1010

Therefore you excluded the 2 highest significant bits from the number. (If you already know this now then sorrrie: I didn't understand the coders block comment)