famous last words…confirmed

So I’m REALLY starting to freak out that maybe won’t get in to college.  Because while I’m certainly eligible, I got this crappy email that tells me: “yeah, you want a student loan?  this is your student ID, which you’ve had since before you were even sudo admitted.”  thanks for being clear, assholes.  I only have ONE WEEKEND to register for classes and get my fukken act together if I’m even in, which I don’t know, because they AREN’T BEING CLEAR.

Okay, thank you for your cooperation in terms of listening to a rant.  WAIT!  IT’S NOT OVER!  Some drunk fucker wandered in to our garage and started knocking things over!  Full story here.

But anyway.  Those it-should-be-easy-to-get-depth-targets-to-work-in-Direct3D last words?  Yeah.  Apparently, it can’t handle rendering to a depth texture, so you have to create a depth stencil render target.  But you can’t just use that.  Ohhh, no.  Apparently depth components can’t be reinterpreted without shaders.  This makes no sense, as OpenGL has had this capability FOREVER.  So it actually takes a simple pixel shader to copy from the depth target to a usable texture, a red only format texture.  Talk about clumsy and stupid.

So the long and short of it is that I now have to have two classes of rendertarget, (yes, even for OpenGL as I can’t break unified API,) one for color and the other for depth.  In OpenGL, it’s actually the same class with two settings.  In Direct3D, it’s two seperate classes.  pfft.  I don’t like it, but I’m pleased to say that the actual API needs only ONE outwardly apparent change.  The CreateRenderTargetTexture() method now has a new argument: targetmode, which can be RAVEN_RENDER_TARGET_COLOR or RAVEN_RENDER_TARGET_DEPTH.  The rest is transparent.

Sooo… yeah.  Workin’ on it.

WOOOOOOO GDB WINS!

So, I managed to isolate EVERY KNOWN BUG in RAVEN so far, and fixed them.  I feel good about that.  In addition, rendertargets are working in Direct3D.  I will add a depth target texture  for Direct3D rendertargets soon.  I also fixed the font not pixel perfect issue with Direct3D.  I had to shift the X,Y coordinates by -0.5, because apparently even untransformed vertices in Direct3D are not mapped directly to pixels.  Stuuuuuupid.  And I also added an alpha argument to the material constructor because having to set it after the fact is just plain hackish.  That also solved the fact that alpha wasn’t explicitly initialized, causing consistency problems.  Big time.  Another bug that was fixed.

All thanks to my l337 programming sk1lz and GDB.  Is there anything GDB can’t do?  Excellent debugger AND payload delivery system if you happen to be a hacker!

All I have to do at this point is get the Direct3D rendertarget working with a depth texture and stick in HLSL support.  It shouldn’t be too difficult (famous last words…lol) so stick around.  Then I can maybe add bitmap font support!  I’ll probably take an Irrlicht approach on that one, I really like their method.  I feel like this project is seriously trucking along!

And… I really hope I get my ACT results back soon enough to register for classes.  I feel somewhat worrisome.  If I can’t follow through, I’ll have to wait ’till next year.  And then I’ll have to wait and feel bad about myself… sigh.  Here’s hoping.

EDIT!

Seeing as how no one has commented yet, I feel fine just editing this post.  Here are some screenshots of the rendertargets working in Direct3D!  OpenGL is exactly the same in appearance, so really no need to post them.

If that isn’t just balling, I don’t know what is.  Next up:  HLSL support!

wooo, fonts! and materials! and manga?

FONTS ARE FINALLY WORKING IN DIRECT3D!!!

They are!  There’s kind of a texture sampling issue with it, but that’s insignifigant, and they look fine.  It might just be shitty Direct3D texture coordinate precision I can’t do a damn thing about.  So here’s the screenies:

Direct3D 9 Test (fonts aren’t quite pixel perfect):

OpenGL Test (fonts are pixel perfect):

It may be a fencepost error on pixel ratio calculation that causes the font pixel precision problem in Direct3D.  I’ll fix that.  But hey, I can now finally get rendertargets working in Direct3D.  Then I’ll implement HLSL support with the same shader object class interface, and I’ll be up to snuff.  I’ll finally be able to start expanding the functionality again.  One thing I want to do is to add a streaming mode for vertex buffers so I can do dynamic vertex stuff.

Hey, did you notice the tasty per vertex alpha there?  The backface culling is disabled for this test, as it would keep us from getting this cool semi-transparent cube effect.  I have a boolean material setting in the material class that lets you switch between using material and vertex colors.  This is clearly vertex colors.

As you can see, I’ve also separated the specular component in OpenGL (using the extension, no multiple pass techniques unless it’s REALLY neccesary) in order to mimic the behavior which is default and usually used for 3D games in Direct3D.  The applications I develop for this should have as consistent and standard an appearance across platforms as much as possible, and this is really the best specular look (fixed pipeline wise anyway) for most surfaces.  If it’s otherwise, there’s always a shader for that.

I’ll have it all caught up on the Direct3D end soon.  At which point, further feature development begins.  Here’s something I want to add: Windows builds will use DirectInput for input.  This will allow me to code for my gamepad, yay!   GNU/Linux will use xorg devices for gamepads, same as all devices on GNU/Linux.  I may need to borrow a friend’s joystick to code for that.  We’ll see.

But hey!  I just recently started drawing manga again, which was my original art style.  I used to only draw manga, which I shifted out of at one point.  But I thought I’d make  another crack at it, and let me tell you.  NOT like riding a bicycle.  I’m just getting back in to it, this is a doodle I did just  a while ago:

I made this in The GIMP.  All tablet, no paper.

Yeah, I know.   Her shoulders are a bit too broad.  I don’t mind it though, the super feminized look is kind of rediculous to see in EVERY female character.  It starts to get redundant and unrealistic if overidealized.  Just saying.  But cool, no?

That’s about it.

lighting problems: resolved

Just a quick post: lighting issues are RESOLVED.  When you set the ambient source to color for Direct3D it multiplies and OpenGL adds.  So I just have to do that part manually for Direct3D and everyone’s happy as a clam.

RAVEN materials + inhuman art + freaky art

I have to say it’s quite awesome that my Grey fanart wound up on the Inhuman site’s fanart page.  I did a thing with grey killing people/trees with a menorah.  That’s because he loves the slaughter portion of the holiday season.  heah yo go my buddayo…

Okay then.  Now that that’s over with, let me tell you about a sweetass development with the engine.

I got simple materials and lighting to work in Direct3D and OpenGL!  Transparent in terms of which API of course.

This next screenshot is simple proof you can choose which:

u can choose d3d or gl zomg

NOW.  Direct3D:

Direct3D 9 HW L&T in RAVEN

And in OpenGL.  OpenGL’s glColorMaterial(GL_AMBIENT_AND_DIFFUSE) appears to give me a slightly brighter ambiance than Direct3D’s D3DRS_COLORVERTEX and D3DRS_AMBIENTMATERIALSOURCE / D3DRS_DIFFUSEMATERIALSOURCE set to the first vertex color FVF.  Not sure why, maybe it has to do with how D3D mixes the ambient color?  Or is that part of the HW L&T pipeline?  I can’t remember T_T.  Whatever, I’ll get this figured out.

OpenGL HW L&T

Oh hey.  I made another art picture yay!

Gynophobia by ~ninjarat1 on deviantART

omg done lol

YOU CAN READ THE ARTICLE BECAUSE IT IS DONE I WANT COOKIES NOW BUT RUSTY NAILS WILL SUFFICE

…

…

…

FAAAALLLCOOOON PUUUUUUNNNNNNCH!!!111!1!!!!1!

so, yeah, read the article.

straight up hdr for shizzle

Here’s one I came up with this morning: reality is to the mind as television is to the eyes.   Oh man, I know that shit was too deep for you.  Sucker.  Seriously though, ponder that.  You should read about the psychological registers of reality.

Yeah. Yeah. I’ve got this HDR under control. The test app is kinda hacked together, but that’s okay, when I add the option to the scene manager to turn HDR on/off, it will be much better. But there is a totally balling video (oh yeah, I said balling. I went there. Yep. Oh. Yes.) on ye grande olde intarwebs, and it may be enjoyed via eyeballs at the location below this text type symbol cluster. Hya!

There is a text line in the video (a bit blurred by compression sorry for quality) that should say when HDR is enabled and when it isn’t. It’s exaggerated for this example, but will be done in more moderation for a game. It shows non HDR first and at the very end so you can compare.

It really adds to the feeling of being extremely bright!  But, unlike in many games, to be truly convincing it must be used IN MODERATION.  I can’t stress this enough.  And while I bash over-use of bloom,  I might as well point out that not everything in the whole world is gloss shiny.  Especially not dirt.  Seriously, just because it’s a new graphics technique doesn’t mean you have to use it on everything.  The only one that counts for is multisampling.  That DOES make everything look better.

t3h engine project + games == omg no work

Seriously.  I have Portal on here now, and beat it, but it ate up like two days of work time.  And also Zombie Panic, that’s still killing time.  At least I don’t have TF2, or I’d never get anything done, ever.  EVAR  :B

aaaannnnyyywaaaayyyy………..

I think the engine project could use some revival.  I like the code I have so far, and I still want to work on Floculate.  BY THE WAY OMFG I SPELLED IT WRONG BITCH.  It’s actually Flocculate.  And the word should be Flocculation.  Oh well.

But I want to revamp it to a certain extent.  Redo the system stuff for Win32/Linux, and less tacked on and more tied in properly support for stuff I plan to use like FBOs.  I also am strongly considering C++ for the Renderer.  The reason I am, is that it is far more flexible from a programming standpoint.

And all you people who are like “ur a devout C programmer omg thats liek total sellouting ur believes wtf!!1!”  Then I’m all “shut up foo!”  Seriously though.  C++ is appropriate in application settings.  Physics is C material.  All the necessary operations can be done in C, and it’s speed critical because it’s done on the CPU (by me anyway.)  It’s a necessity that it be as optimized as possible.  The same way OpenGL and DirectX were both written in C, because they are also optimized system level work.  But the USE of an optimized system level library like DirectX, OpenGL, or Rat Physics, is application work, and if it benefits greatly in terms of development from using C++, I’m down with that.

If you still don’t get the distinction, then either you weren’t a programmer and therefore that section is pointless to you, (you are pardoned non-programmers,) or you’re a dogmatic closed-minded jerk that doesn’t understand “circumstances” and their existence due to “dynamic reality.”  Seriously, take your fundamentalism somewhere else.  Once again, this only applies to the people screaming ‘hypocrite’ at me.  I know they exist, I know a few in person.

BTW, DirectX may be written in C++, we’ll never know.  It SHOULD be written in C.  I know it has a C interface anyway.

EDIT:  SUPER UPDATE TIME!  I now have a name for my engine, and it is made of recursive acronym GLORY!  RAVEN.  It means RAVEN Audio Video ENgine.  BRILLIANCE P0R W00T4G3!  Of course this is a part of Rampancy Engine.  The other part nearing completion is Rat Physics.  I also want to add more components, but that is for another time.

FreeType + OpenGL revisited

Well, when I tried to display text with different vertical extents like lower case ‘g’, it obviously didn’t work, because it simply assumed all characters were the same height.  So, I’ve got new stuff involving metrics for you.  I don’t really have any need for all of them, but here’s an image I ripped off from who knows where, that shows you all the metrics involved in placement.  Search around, I’m sure you’ll find the source.

FreeType Placement Metrics

The image.  The additional metrics I’ve used are height and y-bearing.  It’s pretty simple.  In my original code I had a scale of (1,-1,1) to turn it rightside up.  Then I positioned it at -y-font->pt, which was essentially adding the font height to y, in negative scale.  But since in many fonts, not all glyphs are the same height, you must consiter each glyph.  So I added another metric: float hoss[num_glyphs], height offsets.  This was calculated by subtracting the height from the y-bearing, giving me a negative value.  Then I changed -y-font->pt to -y-(font->pt-font->hoss[*ch]), which gave me the height offset calculated for that glyph.

And the actual code to calculate this was VERY simple.  Given that you’ve just loaded your glyph, (as my article did,) you access face->glyph.  So our old code was:

tf->wids[ch]=(float)(face->glyph->advance.x>>6);

tf->qvws[ch]=bitmap.width;
tf->qvhs[ch]=bitmap.rows;

tf->qtws[ch]=(float)bitmap.width/(float)width;
tf->qths[ch]=(float)bitmap.rows/(float)height;

Yeah.  And then you’ve got the new code, which has the extra metric:

tf->wids[ch]=(float)(face->glyph->advance.x>>6);
tf->hoss[ch]=(float)((face->glyph->metrics.horiBearingY-face->glyph->metrics.height)>>6);

tf->qvws[ch]=bitmap.width;
tf->qvhs[ch]=bitmap.rows;

tf->qtws[ch]=(float)bitmap.width/(float)width;
tf->qths[ch]=(float)bitmap.rows/(float)height;

Now we have the old transform code:

glTranslatef(x,-y-font->pt,0);

Versus the new transform code, with correct height placement:

glTranslatef(x,-y-(font->pt-font->hoss[*ch]),0);

Hope this helps you.  I’ll probably update the article to include this stuff eventually.

quaternions, I can make them work!

Now that I have arc ball working, I will show you what a quaternion is.  I have a couple of screenshots too, and they are here:

It looks like this initially.

Now we have a white circle showing us the grabable sphere of the arcball. The red point is where we've grabbed it.

As we've dragged the red dot, notice how what we've really done is simply dragged that point over on the arcball, and as the point is dragged, so rotates the sphere, and as the sphere rotates, so does the model.

Basically what a quaternion is is a 4 dimensional vector that exists in space over the real numbers.  For the purposes I use it for (rotation) it’s basically is superior, because it can do perfect great circle rotation easily.  The reason is that it isn’t constrained by the Euler representation’s axes (pitch, yaw, roll) which make the question of arbitrary axis smooth rotation much harder.  You have to do something like 3 different space transforms in order to do the rotation, and then you have to go back.  Whereas a quaternion essentially produces an imaginary axis that can rotate as though there were no space transform, because the other elements of the vector are relativistic.  It is very hard to imagine what this looks like, because it’s, you know, hyperspace.  Once the rotation operation has been derived through all that complex imaginary number crap, though, all the imaginary elements are gone, so nothing special is needed for the algorithm.  This wiki page has info on quaternions, and this NeHeGL example is a good demo of how it works.