You couldn't ask for a lamer topic!

[Jupi]

Damn right you deserve it!

[Spectere]

Thanks for the support, guys. :]  I'll let you know how things go.

[OmegaOmni]

When I get back to Ohio you better be ready that weekend I come because we are going to PARTY!

[Jupi]

I'll totally come up for a party!

[Bobbias]

I just wrote perhaps one of the most inefficient OpenGL (technically OpenTK, but it provides roughly 1:1 access to OpenGL in .NET, so yay) program in existence.  It displays bitmaps in the most braindead way imaginable -- by rendering every single pixel in the bitmap as a quad.  Two polygons per pixel.

Not only does it use an obscene amount of memory (let's just say, I cached the bitmap in memory as a System.Drawing.Color array) but the CPU actually gets gridlocked sending that much data out.  I think I get about 3 FPS on a 1280x960 image.  No culling to speak of, so if you zoom threw it it'll still attempt to draw everything.  Oh, I also didn't bother building display lists or anything that could make drawing more efficient.  Take that!

I was kind of disappointed by the results.  I figured that modern CPUs would be able to handle a bit more brute forcing than that.  I suppose now I'll just have to make it a bit more efficient to see if I can make make the GPU try a little.

Edit: Wow.  I threw the entire mess of polys into a display list and now it can do 1920x1200 images at 80-90 FPS on my machine.  I suppose the fact that it made that much of a difference isn't too surprising, but what amazed me was how easy it was to use display lists.  Changing them, however, is kind of impossible.  Perhaps the next step is vertex buffer objects.

This is fun!

Edit

[Spectere]

Yeah, I've written my own BMP loader before.  Outside of some of the odd header fields, the format is very simple.  The only gotcha is that each line has to be a length that is a multiple of 4.  For instance, if you have an image that is 17 pixels wide, each line will be considered 20 pixels.  You would simply plot 17 pixels and discard the last three.  Oh, they're also drawn from bottom to top.  Easy peasy.

I've also written a loader for 256 color PCX files.  Annoyingly enough, the format did not match the specifications. :x  Still, I was able to get it to read them.  I never did get around to finishing that 16 color PCX loader...

[Bobbias]

That discarding thing is kinda lame... you'd have thought that back then they'd do anything in their power not to waste space, considering BMPs were around when memory and hard drive space were still at a premium.

[OmegaOmni]

I'll totally come up for a party!

Hell yeah!

[Spectere]

That discarding thing is kinda lame... you'd have thought that back then they'd do anything in their power not to waste space, considering BMPs were around when memory and hard drive space were still at a premium.

BMPs were never intended to save space or memory (they could either be uncompressed or use RLE, and the latter is only space efficient in very specific cases).  They were intended purely to perform well.  That is why rows are aligned at 4-byte boundaries -- that is the native dword size for Intel processors.  It's faster for it to do that than to read it pixel-by-pixel or read past the end of the line and backtrack.  That also saves them from having to specifically check for the end of the file, since reading past the end of the line could potentially cause that to happen on the last row.

Edit: Speaking of GLBMP, I said "meh" and made it use textures:



*VERY SLIGHT* framerate gain and a major reduction in poly count.  Gee, I wonder why!  I have to say, video cards are much better at handling 3982x2987 textures than they used to be.  I've been learning quite a bit about fill rate during these wonderful experiments as well.  Fun fact: zooming into the image that's currently loaded causes the framerate to increase as you get closer.

There is also absolutely no perceivable performance benefit to using display lists on a two poly surface.  Who woulda guessed?

I think my next step will be to divvy up to the surface and make it wiggle and stuff.  Wobbly windows, here we come!

[Bobbias]

I'm still surprised that they didn't try to engineer some space saving stuff into the format. It just seems that everything from that sort of era had space saving techniques and such applied to them.

I need to get back into programming. I'm currently trying to make a simple game kinda reminiscent of nethack etc. using console "graphics" (in other worse, codepage 437).

[Spectere]

They did try to engineer some space saving stuff into the format -- RLE.  Basically, if there was a straight run of 50 pixels with the color index 5, it would simply have something like 0x32 0x05 rather than a straight run of 0x05.  It had the advantage of being very fast, even on 8086 systems (which is what DIB/BMPs were made for, really).  PCX's compression is nothing more than RLE, and it was popular for the same reason -- it was fast, even on low-end systems.

With speed comes a price.  If you have an image that consists of nothing but vertical bands, RLE isn't going to do squat.  But considering actual compressed formats like JPEG were known to take up to a minute to display on a system that could bring a BMP up instantly, I don't think people were too concerned.

[Bobbias]

Ahh, I didn't realize BMPs have RLE in them. It's too bad RLE only works for horizontal runs though.

[Spectere]

Yep.  It does make sense, though, since that pretty much matches how linear video memory is laid out.

[MortifiedocAlot]

Aubrey Plaza is adorable.

I feel wildly depressed, and I don't think I can properly vent about it.

[Spectere]

So I've decided to use Internet Explorer 9 this week because Chrome's performance has been getting worse and worse these past months (I've experienced this issue on my i7-930, an i7-950 at my old job, an iMac with an i3-530, a Core Duo 1.73GHz, and a Pentium-M 1.73GHz, so it's definitely related to Chrome itself) and Firefox isn't doing anything to wow me either, especially with their new extension-crushing versioning system (which effectively nullifies the main reason people have for using Firefox in the first place...go team!).

It really kind of amazes me that Google, of all companies, doesn't make any attempt to take advantage of some of the neat features in IE9.  If you have Windows 7 and IE9, sign into Windows Live using IE9 and drag the tab to your taskbar.  Close the window and right-click the icon.  It displays a task list like an actual program, displaying a crisp icon and allowing you to jump directly to your mail, calendar, etc.  Yahoo?  Same thing.  Google?  Hell naw.  Even though the number and richness of services that they provide, not to mention their cloud philosophy, would make that a perfect candidate, they neglect to support the dominant browser on the dominant OS.  Here's a hint, Google: ignoring IE isn't going to help you sell more insanely overpriced Chromebooks.

Speaking of ignoring IE, you should see the treatment that Google gives Windows Phone.  Even though my phone can support the full version of the site, Google has the audacity to deliver me a fucking WAP site for their services.  Really, Google?  If IE was still outdated that would be one thing, but IE9 is a very competent browser.  Last time I checked, it offered the most compliant ECMAScript implementation out of all the major browsers in use now.  IE10 only fails 4 tests, which is simply incredible considering other browsers tend to fail hundreds of them.  And yet I get served a WAP site.  Good show.  Really.  It's a good thing WP7's mail client has native support for Gmail, because the way it treats modern mobile IE is just insulting.  And here I thought that Google was a cutting edge company supporting the latest web technologies.

Edit: Well, I went off on a tangent there.

To conclude this blahblah-turned-rant post, I'm probably going to use IE9 on this system and Opera on my laptop (which is running XP, sadly, and can't run IE9...sigh, why did the video card on my newer one have to commit seppuku?).

Edit