My texture coordinates had some minor issues as well. Thanks to the
“show normals” shader in ATI RenderMonkey I was able to visually verify that
all normals and texture coordinates are continuous and correct.
I also spent some time writing code to generate the tilt knobs that will be
on the sides of my mounting box and added code to generate polygons for the
underside of the maze. So theoretically, you could now view the maze from
below as well. This also makes my entire geometry solid, meaning that there
are no leaks where you could see ‘inside’ an object, which is important if
I decide to try myself at shadow volumes later in the project.
For the rest of the day, I’ve been improving on my usage of the XNA model
classes and then designed a little scene graph system, as seen from the
current state of things, this is the cleanest way to decouple the scene
from the game logic. I need the scene building stuff separate because I want
to create a cool level selection system which renders previews of the maze.
It wouldn’t be the best thing to always have the game logic all over the
place when I just need an image of the maze!
Have… to… continue! Yesterday, I bought Gothic 3. I have played all its
predecessors and the entire series is highly addictive to me. This will wreak
havoc on my development of this little project.
Anyway, as I found out, it’s not possible to load .x files with the XNA beta
yet, so my original plans of modeling some stuff in 3dsmax will fall flat.
Maybe I could use the Mesh classes to still get some vertices loaded, but
since there’s only one non-dynamic shape (the knobs on the sides of the board),
I’ll just go ahead and build my geometry programmatically.
After checking out some phong shaders I found on the need, I noticed that my
normals still weren’t right for the walls. Turned out to be a minor typo.
With some lighting, everything is looking so much better. I’d love to add
shadowing, too, but I feel that it’s too complicated to tackle just now.
My wall geometry generator now produces proper normals for all the walls so
the lighting should now yield the results I’m hoping for. Because I’ve never
done shader programming before, I downloaded ATI’s RenderMonkey in the hope
that it could help me create some simple shaders nevertheless. Not only did
RenderMonkey give me the exact shader I needed to test my texture coordinate
generation code, it also greatly increased my understanding of shaders with
its excellent shader code generator.
So now that the walls were working, the floor came up on the task list. Normal
floor plates are just boring quads, but making holes in the floor was a bit
more difficult. In the end, I simply arranged some vertices in a circle and
built triangles from the circle points to the nearest corner of the
surrounding floor tile.
So this is what I had at the end of day 4:
In case you are wondering why the floor texture is so smeary,
that’s intentional. Otherwise, as long as I don’t have lighting
implemented yet, you wouldn’t be able to see the walls clearly in a
static screenshot 🙂
The wall generation code has finally taken shape and generates the vertices
for the walls exactly like it was meant to be. Vertices are optimally shared
between the walls and no polygons are ever generated that the user wouldn’t
be able to see. The code also avoids T vertices in order to prevent
flickering pixels at the wall junctions.
Nevertheless, I fear I will have to change this code soon.
It currently doesn’t generate texture coordinates and the shared vertices
will become a problem if I want a continuous surface on my maze walls
(which I plan to do by calculating u,v as x+z,y – which doesn’t work for
the top of the walls since y [==v] would be the same everywhere).
Plus, the current code generates normals that are diagonally pointing away
from the walls. If I would use these normals for ligthing, the walls would
look as if they were rounded. I’ll still have to see whether I’m going to
use normal-based lighting at all.
After taking an in-depth look at the XNA model classes, I decided to build
a special MazeModel class that would construct a model from a maze provided
to it in its constructor.
That took most of day 2. While writing the mesh generation code, I noticed
that my original idea with equally sized tiles and walls that only used a
fraction of the tile they were on didn’t work out. But because I had already
made the decision to limit the tiles walls can be on, it was not a drastic
change to use alternating tile sizes.
It took me some time to figure out how to organize my code so it fits in with
the XNA framework design. Because the game is so small, I did this by building
some dummy classes and that I renamed and moved around in the project tree
until I had reached an adequate design.
Maybe some people would have used an UML prototyping tool, but I am used
to thinking in terms of design and code, so, just like a good chess player,
I can see when a design will work out or when it will blow up.
Then I identified the hardest, probably most demotivating task at hand. If you
can, I think it’s always good to start there because this is likely the point
where you would "postpone" working on the project for
the rest of eternity.
The hardest part in this project seemed to be the dynamic construction of the
level’s 3D model out of a simple text file that defines the maze using pure
ascii characters. You have to create a bullet-proof parser and then somehow
build a contiguous vertex array for all the walls, floor plates and holes
in pure code.
So day 1 ended with me writing a parser for the textual level file format
I have layed out before.
Today, I started development on my first XNA game. It will be a rather simple game, the real-world
version of which I once played in my childhood. This should allow me to get up to speed with
the state of the art in 3D accelerated rendering again.
Because I have a job that requires me to sit in front of a PC for more than 9 hours a day,
my interest in development at home is fading a bit. I hope this game will rekindle my interest
for game development!
Back to the game, what I decided on is a simple game of balance where you have to carefully
tilt the game board to maneuver a little ball around obstacles to the finish:
Because this is such a simple game, I will release it for free and in full, that means with
all notes and its source code!
Recently, I’ve been reading books one and two of the Dragon Temple Trilogy by Janine Cross.
This series has generated a lot of negative feedback from other bloggers. The funny thing is that
some of them openly admit never having read the books at all, whilst others make absurd statements
about what is supposed to happen in the story, so conclude yourself whether there is anything to
read out of those “reviews”.
The heroine of our story, Zarq, grows up in a society where women are treated as inferior
to men and even sold into prostitution on a common basis. Dragons are as common in this
world as maybe horses in our reality. And althought the dragons are being worshipped as
divine beings, they suffer a fate no better than the women, the vast majority being crippled
by amputating their wings as hatchlings, only to be used as laying hens or working slaves.