Time Warp

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

aaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

aAAAAAAAAAAAAAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhHHH

HHHHHHHHHHHhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

MAKE SOMETHING IN MAYA THEY SAID

JUST A SWEET TRANSVESTITE FROM TRANSSEXUAL TRANSYLVANIA THEY SAID

Phing Phang Phong

Hello mi fren!

Low productivity week due to nihilism.

Added specular component to Renderer, also Phong shading.

Its all very shiney and slow. Needs moar complicated models too, in order to enhance show-off capacity.

Signing off.

Wet Metal

Merry everyone! Heylo guise!

Its not a very straightforward day today. At first I was all like "Yeah man, lets do some Unreal Scripting!", but then I got out of bed and the harsh light of day was not so welcoming to the idea. I say hello to Mr Kenji-san, but his mind was  plagued by the cries of unborn software renderers, and as such he was creatively incapacitated! So I whipped out the 'ole XNA and decided to destroy the heads of some penguins.

In my youthful ponderings on the inner workings of the vidya game, there were many things which, when logically digested, served only to confound. One of these things was persistent blood-splatter. How do you splatter blood everywhere? Why do you splatter blood everywhere? Can you please stop splattering blood everywhere? And other such questions. 

Today, I saw the light! It was pretty obvious really....

I took the smear layer shadery thing from the previous post and extended it to sample from a masking texture which determines whether or not the smears fade, then I combined the effects of two versions of my particle system to make some awesum bloods. Also Sprite by Freezepop mi frennn:

This took about 7 hours. Most of this time was spent figuring out why I couldn't sample from the freaking texture all of a sudden (PROTIP: spritebatch is made out of vile hatred and register(s0)).

MOISTSPACETREE

Salutations fellow coders.  Kenji-san and I have just attempted another all-night XNA session, however we crashed at 6am slept for longer than the agreed sleeping time! Unprecedented fail!

On the brighter side of things there is a small morsel of a game to show for our efforts. However, in a style that is becoming typical of my coding sprees, the 'game' element isn't really the strongest force in the creation. The idea was a large chunk of space that two players could roam around in, and chase down enemies if they felt like it. It was supposed to feel a bit more like a petri-dish though, in that everything should have an organic side to it. Admittedly it looks a lot more alive when you play it than in pictures since everything in the game is restless and insists on wriggling around.

The colour of the world (the gas clouds and the random bits floating about), changes as you travel through the world... I was inspired by interpolating light across triangles to interpolate colour across the gameworld.

This project also gave me an opportunity to do a little bit of shader writing, which had been on the back-burner for a long time. The same particle effect system used in FarmFury was employed here, with the exception that I drew all effects onto a 'Smear' layer, which does exactly that: smears stuff across the screen (and gradually shrinks and removes the muck too).

Also I played around with my renderer until I got it running with dual viewports at a decent resolution. The characters can only run about on an 8 by 8 patch of ground though (98 polys), which makes 242 polys before culling & clipping for both sides to deal with.

Textured Fury: Cow Up Forever!

Good morning everybody!

Kenji & I have rigorously play-tested and tweaked Farm Fury. We added 360-pad support and some new textures too. It's nowhere near releasable, but that wasn't the final goal for the project in the first place. It is, however, a most enjoyable dalliance. This is what its looking like right now:

It would be possible to sit around all day meddling with the mouse & cow stats, not to mention the particle effects...

In other news, the 'ole renderer has progressed a bit. My main aim was to add make it more game-worthy, which meant the following:

• Texturing! Models and terrain can now be drawn with a texture :) If you go over the x and y boundaries of the texture with uv co-oords it wraps back to the start. This makes tiling a texture across the terrain pretty easy.
• Backface Culling! Ok so this doesn't really deserve its own bullet point as it probably took all of 1 minute to implement once I realized how it worked, most of the code was already there, but it certainly helped performance.
• Low-res mode! Currently I have switched the viewport size from 800x600 to 400x300. The final image is scaled up to whatever res you need after the rendering has taken place. This has ramped up the frame-rates of running across the terrain to an acceptable (game-worthy) level.
• Multi-viewport support! Simply make a second camera, and call draw again with the new one. Current limitation is that all cameras must output to the same size viewport. This gives rise to the potential for a two player game.. however the spilt-screen frame-rate is pretty bad right now. Any game with dual (or even quad :O) rendering would have to be graphically much simpler (read: no terrain), and perhaps further restricted to 320x240 viewport size.
• Animation switching... There's probably some better words for it. All models now have the capacity to dynamically change their current animation based on their physical state (Running, Still, Falling, Jumping, Colliding), an enum that must always be provided to the entity by any type of Physical Object. Of course I have to write the animations first, but right now the robotman can switch between running and still just fine :P

Pic:

Sayonara!

15 hours later, can you cow up?!

Yes, I'm proud to say that i can.

Kenji-san and I finished (lol) the prototype game about 20 minutes ago, and just did some play testing. Total development time was 15 hours. The first was spent on planning.

Stuff that happens:

• Two player game, each player clicks on and drags icons from their sidebar onto the screen to create cow or mouse factories, or to upgrade them.
• Cows and mice spawn and proceed to duke it out in the centre of the map.
• Cows and mice die in an explosion of gore.
• The players can switch to hoover mode, and hoover up the gore, in order to get money for building and upgrading new factories!
• If your office (the thing with the big pentagram on it) gets blown up by the kamikaze farm animals, then you lose mi fren!

Here is pretty video:

Its called Farm Fury btw. This was a bit of a randomly generated idea we had a while ago, and finally stopped taking drugs long enough to make it, ha!

Tooooooodles

This weekend's output

Hallo again.

Since this whole 3D rendering malarky is about getting up to scratch on the various conventional wisdoms of 3D graphics and programming in general, I decided to try and implement a few other fairly commonly used features into my little engine.

• Terrain generator! It uses perlin noise to create a square patch of terrain, and then averages out all the vertex Y values to make it much smoother.
• Per-triangle terrain collision! As my small running robot fella travels across the world a point at his feet is checked against the triangle he is currently above (or below, but he's generally above things). The exact height of his (X,Z) position on the triangle is calculated using bilinear interpolation, and if he's below it, he's snapped to the surface.
• 3rd Person Camera! At the moment it only follows and rotates with the robot, however adding rotation around the X axis, like in a third person shooter, is on the todo list, along with camera-terrain collision.
• Erm, class structure? Looking through unreal script I really liked the way that there are two separate classes for which can be combined to make an entity in the world. They are the controller and the Pawn. Once defines the actual 3D object with its functions and animations, and the other defines how it is controlled. I have made an attempt to implement a similar structure here. The Entity class contains a Model, a Controller, and a PhysicalObject. Which all feed eachother information through standard functions whenever the entity is updated, and which are all updated separately, by graphics, control, and physics managers.

Here is video:

As you can see there is still a fair bit of optimizing which needs to take place, also the collision can be a little sketchy at times. Also, clip planes in action!

Next thing to do is definitely back-face culling since I needs the speed. 

Following weekend is going to be consumed by unreal script/level making,  expect more in two weeks! 

Right now Kenji-san and I are about to embark on an all-night XNA project (deadline 10am), I'll post our creation when I have time.

Byeeee

Something grey and scratchy

Hallo.

My original plan for this week was to gut all of the content from my previous game, extend the rendering capabilities, and make a new game; this hasn't happened. 

Instead I decided to stop dicking about with pseudo 3D stuff and mash out the full renderer (or at least the core of it) in a blitzkrieg of code and relentless. Animating simple trees and spiders had got me in the mood for some more procedural animating too, so I decided to trial-run  my new renderer with a procedurally animated robot-man. The code I used to move his arms and legs was very similar to the methods used on the spiders, with the exception that I extended the algorithm to accept more parameters, so a greater range of 2-bone relationships can be created. Thar she is:

Technical crap. 

One of the first things I did once stuff was drawing on screen was try to optimize, as it was hella slow. Aside from standard stuff like avoiding divisions, not assigning memory more often than necessary etc... the thing which really made a massive impact was switching from using Gdi's Bitmap::SetPixel(x,y,color), to using a unsigned char* to directly edit each byte of colour in memory.

Each frame the renderer draws to a bitmap, before drawing the entire thing to screen at the end of the frame. In the previous aberration I was drawing directly to the screen using lots of small rectangles for pixels.

As for shading, I decided that Gouraud was the way to go for now, especially since I actually want to use the renderer to make a playable game. This probably took the longest out of everything to get right, although when I started implementing the shading I didn't really know what I was doing either.

To create the human I made Model and Bone classes, with the idea that a bone can contain its own child bone. However I ended up just chunking a whole bunch of bones inside a MHuman : Model and writing the code for the animation directly into MHuman. In retrospect, had the ends of the legs and arms been child-bones of the top parts it would have made my life easier. This is right at the top of the todo list next time I make a model. 

The human is made out of lots of differently-scaled versions of the same shape, each created using the same function. Hardcoding even that simple shape (10 verts, 16 polys) took a long time, so I think all my future content will have to created in a highly algorithmic way... I mean, I could just make something in a nice 3d rendering package and write an importer... but y'know it just wouldn't be the same :P 

Massif props to Bob Powell, whoever that is, for explaining about locking and unlocking a bitmap's bits in his Gdi Faq.

Also massif props to Lukasz Pasek for many little tips on Gdi+ and shading!

Adiós

Virtual Deconstructors!

Wow, turns out all the stuff I was going on about type casting was, while useful to know, unnecessary! When you delete a pointer of BaseClass* type which points to an InheritedClass object, all that needs to happen to get the base class to delete the inherited one correctly is to make the base class's deconstructor virtual. One word in the header file. Super easymode.

instead the VS2008 default of:

public:

BaseClass(void);
~BaseClass(void);

you have:

public:

BaseClass(void);
virtual ~BaseClass(void);

Thats IT!

Woo.

I am finished with the building!

I am a naughty child :) I have allowed my weekend of coding to overflow into all of Monday. Good news is this little project is done now. Here's a little video of it in action:

Things that have happened:

• Death sequence for trees and spiders. When they die, trees disappear segment by segment from the ground up because I thought it looked funny, and spiders go black and shrink... kinda like real spiders.
• Rebirth! Tiny spiders appear and start running around, scaling back up to normal size over 15sec. Trees respawn as little stubs and scale up over 10 sec (while continuing animation).

As far as features go thats about it. Most of the time was spent on fixing bugs, finding and murdering memory leaks, and trying in vain to get better frame rates when fire is everywhere.

Since this has been my first real project using c++, solving all the errors and bugs has been great for developing my understanding of the language, one thing i thought was interesting:

Type casting. I had an issue where the program would randomly crash due to corrupted heap, the reason, I discovered, was down to some of my deconstructor code. In two places there were lists of pointers to a base class, which lots of things were inherited from. I would cast the children onto the base class and add them to the list. When I wanted to delete everything I iterated through the list and deleted all the pointers, however it was only deleting the inherited objects as though they were their parent class, so the actual deconstructors of the children never got called.

Turns out i needed to use typeid(...) to get the fully inherited type of the pointer, and then reinterpret_cast<...>(...) the base class pointers into their child types, before deleting them.

More next weekend!

Toodles

Nearly there, perhaps...

Phew, so thats officially the end of my weekend coding session. Incidentally its also the end of my weekend, so I didn't really have much say in the matter. A recent screencap of my creation:

Things that have happened:

• Spaceship: hardcoded; weighs in at 16 polys and 24 lines. Gently bobs and rotates. 
• 2D mouse point projected onto plane in 3D. The cursor has been replaced by a translucent square, the centre of this square is projected onto the 'visually accurate' position on the plane that is the ground (fps style). The position is used to move the spaceship, so that is it hovering above it. Essentially, mouse moves in 2D world across screen: spaceship moves in 3D above ground.
• I got the formula for this by re-arranging the 3D-to-2D one, look at the previous post if you're havin a confuz, it looks like this:

_3dPoint._y = yPlane;
_3dPoint._z = (yPlane * FOCAL_LENGTH)/(_2dPoint.Y - VP_Y) - FOCAL_LENGTH;
_3dPoint._x = (_2dPoint.X - VP_X)/(FOCAL_LENGTH/(FOCAL_LENGTH + _3dPoint._z));

• Tree animation! Re-engineered the algorithm so its prettier to look at. Individual branches move independently while the entire tree sways left and right, also the amount of movement increases towards the top, like a normal tree (it still looks like seaweed though).
• Lightning! Click/Hold the Left button to strike the ground beneath the spaceship with a lightning bolt. Its pretty much just 2 lines each made of 5-6 points which get a new random x and z value each frame (y values preserved). Simple enough but it works ok.
• Fire! Wherever the lightning strikes, burns. If it hits the bottom of a tree, the fire will spread up the tree. If it hits a yucky little spidery squit, that burns too (the fire travels with it on its back). Each fire burns for 5 sec.
• Game-ish elements.... Every time you burn something you get a point :) As if you really needed the motivation.

At the moment there are some performance issues with the fire since it involves drawing a great many shapes and Gdi+ is slow. However there is one optimization that I haven't got round to working in yet, and it is very closely tied to a memory leak which took about a million trillion years to find:

Using Gdi+'s graphics.fillPoly(...) function, you need to provide it with a Gdiplus::Brush (which contains info like what colour to use). This was an unexpected turn of events when I was coding that particular section, and as such I only had a Gdiplus::Pen available. 'Ahh, not to worry' I thought, 'I can simply use the pen.GetBrush() function to retrieve a brush from the pen!'. Well it worked, but I didn't realise that it created a new brush each time, and I had written the GetBrush() directly into the arguments for the the fillPoly function. Every screen drawn was costing me memory!

Anyways, the final goal for this project now is for burnt things to die and new ones to spawn. Trees will grow to replace burnt ones, spiders will spawn very little and grow to replace their dead too. An ongoing simulation of burning strange creepy icky horrid little messes of a creature called spider, of burning peculiar wiggly fronds of seaweed, and of their subsequent rebirth. Great!

Toodles

 

It grows!

I haven't slept recently, and consequently my small spidery bit has grown into a larger multi-spidery-combination-seaweedy bit. The pic doesn't rly do it justice:

The 'trees', which is what I called their class although I prefer to think of them as seaweed fronds, have been procedurally animated too, so they sway gently in the breeze.... Well they did all sway the same way, but then I discovered it looked cooler if I de-synched the swaying, so now its more like they are being troubled by a gently troublesome tide. 

In addition I have given the yellow spiders a mind of their own so they just wander around sniffing about (insofar as a broken spider is capable of sniffing), within a predefined area. Not really sure where this is going next, mostly because vista restarted due to updates and murdered my todo list.

Technical crap - this is generally how it works so far:

• GameObject is (sort of) the base class, and it contains basic stuff like virtual update functions and matrices

• All high-level things that exist in the game(lol), inherit from the abstract Entity class, which in turn inherits from GameObject
• Anything which inherits from Entity will contain a list for things which inherit from DrawnObject
• DrawnObjects are also inherited from GameObject, and contain a list for Lines, and a list for Shapes
• The spider is an Entity, it contains legs and a body, which in turn are DrawnObjects, made out of lines and shapes
• The scenery is an Entity, it contains trees and the background, which are DrawnObjects etc.
• When it comes time to draw the scene the entity class stuffs some pointers to the contents(lines & shapes) of its constituent DrawnObject list into a 'DrawPackage'.
• DrawPackages hold pointers to things that want to be drawn, as well as the mean Z co-ordinate for that item.
• The DrawPackages all get transformed by the relevant matrices before being shipped off to the DrawMachine, which waits until all are present before Depth-sorting and ultimately drawing them to the screen.

Dunno if all that makes sense..it's a rough overview anyways. Even though I set out to design it in a highly OO style I can see many things which I would like to have done differently, if I could be bothered to do it again... And I suppose I will be bothered to do it again since it's an assignment, ha.

Sayonara 

Something small and icky

O hi, I was just in the neighborhood and thought I'd stop by for a quick chin wag.

Furthermore, a picture which doesn't speak anywhere near 1000 words:

We have to make a software renderer using GDI+/C++ for Intro to 3D, so I figured I'd go off on a bit of a tangent and make a horrible little skittely spidery thing that looks more like two horses duct taped together. Since its early days on the 'ole 3D rendering side I cheated, and used a different formula to project my 3d points onto screen space:

_scale3D = FOCAL_LENGTH / (FOCAL_LENGTH + _3dPoint._z);
_2dPoint.X = (Gdiplus::REAL)(VP_X + _3dPoint._x * _scale3D);
_2dPoint.Y = (Gdiplus::REAL)(VP_Y + _3dPoint._y * _scale3D);

Copypasta'd straight from the source mofo. Where VP_X and VP_Y are the coords of the centre of the screen, and FOCAL_LENGTH is 200 (it can be anything but values around 200 work best).

So far the little enginey thing supports drawing rectangles, ellipses, solid-colour-filled polys (up to 20 points), and lines. The little purpley thing is a spider with deep seated identity issues. Its legs are animated procedurally, although right now it can only run and be still (more to come!). I love making silly little creatures so hopefully soon you will see a field full of multicoloured animals getting Toblerowned (or possibly Sylvester Stallowned) by a small man with a club.

Also, massive props to Kenji-san for finally figuring out the Gdi-flickering issue.. he's making some variety of tetris clone using winAPI and thus is a very useful fellow.

Toodles

Resident Evil Unreal Task

Watcha guise, heres some useless and sweet-tasting snaps of my contribution to our class's rendition of the resident evil complex. Yup. I made a corridor of all things.

It was fun carving out the world and playing architect. 

..but I wasn't really happy just making a long tube-like edifice so I added a cosy little room as well.

Snug!

The whole project came together pretty good,  however a quicker and cleaner solution for linking rooms up would have made the whole end-user experience about 1000% better. As it is you have to "click fire to play" on entering each room (with 5 sec wait).

Toodles

Disassembling Jaguar Games...

...is a long and convoluted process it seems!

The best source for all things Jaguar I have found is the Jaguar Sever Homepage which contains pretty much everything a budding Jaguar hacker could hope for, unfortunately though if you're running 64-bit vista or windows 7 then hoping is about as far as it gets.

Sooo it goes a little something like this:

The Jag has three main processors, Tom, Jerry, and a Motorola 68000 who was picked on unrelentingly for his silly name. Srsly though, Tom contained the main dedicated GPU, in addition to the 64-bit object processor, and blitter chip (which is where the 64-bit ends). Jerry did all the bitch tasks like sound and Input whilst also being available for other non-specific stuff if the occasion called for it.

The 68000 was, and still is, a general 32-bit control processor.

This gives us quite a few disassembly options; however...While Atari ranted on about how developers could use the 64-bit blitter for all their logic processing needs this turn out to be a tad more involved or at least non-deadline-compatible than game devs at the time cared to be complicating their lives with. Consequently most game logic was processed on the 68000. 

For the sake of interesting times in assembly I decided to attempt to disassemble some of the 68000 code. 

If you are really eager and have already clicked on the Jaguar Sever Homepage link up there you'll notice the only option for 68000 disassembly seems to be a program called "easyrid4", which 'runs with' a Jag emulator (?); well it certainly wasn't content to run without one... The emulator Pacifist being the only suggested option I install it and discover that I am not DOS and that this just doesn't sit right with it. Not being one to give up that easily I crack open the DOSBox (a DOS emulator) and then attempt to emulate my emulator (ha)... Ultimately I am met with some variety of 'deferred success'.

I think I'll wait till I regress into a nice retro-friendly OS before having another stab at this, in the mean time there are plenty of  more popular retro consoles to satiate my disassembling desires.