Peter Lewis’ Portfolio

Here I am, back at University and with my own Internet connection. Apparently they have wireless in the library now, which is awesome and sustained me during the period where I lacked a connection of my own.

It should be an interesting year. I’m looking forward to my modules, but possibly not all of them. I will need to pull some enthusiasm from within myself somewhere, but I think the reason I am not looking forward to these modules is because I have no idea what to expect from them. I know that I’m doing a raytracer this year and I can’t wait.

I’ve also made some headway with my scripting language. I have currently got a decent lexer going now that I can - handily - plug into anything. It’s only a primitive version, but it can parse pretty much anything. You can even define your own symbols and operators and it will parse those just fine. It is based of the SCL, so I doubt many people will ever use it except me as the SCL is so far removed from traditional C++ that it puts most people off.

I will post the library and header on the downloads page and if anyone wants it they can have it. It’s useful, I swear.

I have just been presented this link, which is the most incredible thing that I have seen all year. The videos are fantastic and I recommend watching them. What shocks me most about all this is that it was created by three guys in their apartment, who are apparently the same guys that did Savage.

Also, this makes me re-think what I think NFJ Software could do. We are were 2 programmers, a level designer/programmer and a designer until about 4 weeks ago when our level designer, Luke, got a placement. Now that he’s creatively incapacitated for a year, we have absolutely no artists or level designers. Chrissy is hoping to fill in, but he’s never done level design before. I’ve met two other guys recently who might join the ranks, but they’re also both programmers.

You may notice the lack of any arists. This is our major problem at the moment: we don’t know any artists. Actually, we do, but we haven’t found any that a) we find easy to work with, or b) have the level of talent we are looking for. Yes, yes, I know that we can’t afford to be picky at this stage, but none of them match (a) which is a mandatory requirement.

In other news, I have nearly finished the SCL3D. All that’s needed now is a camera interface. Also, it could do with some preliminary model format support, but that’s an optional feature.

So yeah, Jack Thompson’s an idiot, but we all knew that.

Sorry about the lack of updates recently, but I’ve been busy working on getting the SCL ported to a static library. I’ve also got an offer from a guy I know called Mitchell Taylor who lives in New Zealand for a sound library that he’d like me to include in the SCL. I think I’ll have it as a separate library and release it under his name … he’s far to modest for his own good!

All I have to do now is fix up the renderer into a static library. I started doing this because I hit a design issue (see below - I put a hack in but it’s no good really) so I’m restructuring it. Then, just maybe, I can finally start on shaders. I want to get this perfect before I deal with them, as I know from previous experience that they’re a bit of a bugger.

I’ve been going mad over asset management over the last few days. Everything I write, I hate. I cannot think of a good way to efficiently and cleanly handle asset data.

The goals of the asset management system are:

• To manage the releasing of assets at shut down time.
• To prevent an asset being loaded twice. I thought about having this in a file loading registry instead. This would probably be more sensible.
• To allow the asset resources to be flushed and regenerated at any time (such as textures).

I know this should be a simple task but I just can’t think straight. I know I need a reference to the asset, I need the asset data so that it can be regenerated, and I need the actual asset data. To clarify:

• The asset reference points to the generated asset. For example, it would store a pointer to a IDirect3DTexture9 object. Many of these objects share this pointer and when the list is regenerated, their pointers are updated.
• The asset data is the raw data that is used to generate the IDirect3DTexture9 object.
• The asser resource is the encapsulation of the asset: it stores the IDirect3DTexture9 object, for example.

Has anyone got any ideas? I’m getting the feeling I’m just being stupid and I’m trying to think of this in a way that’s overly complex and is obfuscating the simple answer.

First off, sorry about the mass of “File:” posts that just appeared below. I’ve just updated my Files Section, so I had to re-post all the existing files. Please take a moment to browse around and let me know what you think.

Today has proved more fruitful than yesterday. Yesterday I did a lot, yes, but unfortunately none of what I did was very good. Today I have compensated this loss by deleting what I did yesterday and starting over. To be fair I was not feeling too good yesterday.

I was working on a scenegraph for the renderer, which I have now implemented to my satisfaction. It’s only a basic one, so at some point I will be extending it to cover culling et cetera. At the moment the program only renders two textured pyramids. Not much use for culling just yet.

Tomorrow’s job is probably cleaning up and looking into shaders.

I’d quite like to get into this. “Climax James” as I’ve come to call him* has just returned from the XBox 360 XFest and refused to tell me anything about it despite my probings. He did say, however, that he regarded it as a superior platform and that it is extremely easy to develop for. I was pleased with this as I hope to work on the 360 at some stage.

What he said about the GameCube was interesting: he said that it’s just as easy, if not the easist console to develop for. I’d never really considered the GameCube before and I couldn’t tell you why either. I took the opportunity that evening to have a poke at a ‘Cube and I still hold by my original thought that it’s an extremely weird looking console. Now that the “next generation” of consoles all look like they’ve been designed by failed graphic design students turned alcoholic, it seemed to look slightly better when I held it.

I’ve heard it said that the ‘Cube is the most difficult console to chip, which is not surprising considering its unique approach to various things such as data storage. It’s got an ATi graphics card in, which I was impressed with. Seeing Mario Sunshine played on it with it’s water shader and subtle little effects made me think that there’s more in that funny-looking purple box than I originally gave it credit for. It has a LAN connector and apparently there are wireless adapters out there. Sounds lovely to me. Of course, the 360 does all this but better, but that’s a whole new generation of console. I’m surprised the ‘Cube didn’t make more of a show of these features in it’s day.

I think I will write to the University and see if I can convince them that GameCube development kits are a really good idea.

* I know so many James’ that I have to give them tags.

I couldn’t sleep last night so I had a stab at some GameBoy Advance programming. I found some old C++ code that I’d written for it ages ago and I realised that it was probably the best code I’ve ever written. However, it was not optimised and despite working very well, it did not work very fast.

I started a new project and twiddled a few things, set up some #defines and typedefs, etc. I then started writing a memcpy() clone. Now I could write this in C in 2 or 3 lines, but I thought I’d have a go at it in inline assembly. I discovered a few things:

• This site (GBA Dev.net) really helps. I recommend it.
• GCC’s inline assembly format is disgusting. However, it forces you to provide all the information that the compiler needs to reduce the risk of crashing and for optimisation. But the drawback is that it’s really horrible to work with.
• The ARM7 instruction set is more expansive than I once thought it was. It actually has operations like “mvr”, which means “move reverse”. This copies memory but also inverts the bits as it goes. Interesting.

To be honest, I did not get any sleep so anything I did find out yesterday wasn’t investigated in the depth that it should have been. I will try and make up for this later. I’m thinking of trying the DS instead, but if I did that I’d probably stick to C. Seeing the objective is to learn more about the ARM7 instruction set that’s an idea I dismissed quite quickly.

The current plan of action is to do a bit more investigating and try and make a little game out of it. Something cheap and nasty probably, like another Pong clone. Or maybe “Dangerous Dave in ‘Nintendo Nightmare’”.

I’ve literally taken 5 minutes to get multitexture working while at a friend’s house. My respect for Direct3D has been moved up another notch.

So far I’ve only hit one platform difficulty. This isn’t particularly amazing, but it’s just something I’ve noted. On the laptop, I have no hardware vertex processing (because the laptop has a rubbish SiS graphics chipset), but otherwise everything works like normal. When I start implementing shader support in the renderer things are going to be different; although it could be worse: I could be doing it with GLSL instead of HLSL.

I look forward to the day where I would write some shaders and they worked first time on every chipset. I look forward to that so much. In fact, I spoke to the head of the Microsoft DirectX division (I have forgotten his name, shamefully.) about this “war of the graphics card vendors” at the GDCE last year. He suggested that I take this complaint to the culprits themselves - ATi and nVidia - in order to convince them that they should meet some kind of standard lest they kill eachother. While this would be a worthy cause, I don’t feel that I’m in a position to deliver such a message.

Yet.

Tomorrow I plan to implement a few things, the most important being a scenegraph. After that, I can move on to getting a stable world up and running - I was thinking of writing a DLL system as a temporary measure. Once I’ve done that I will hopefully have a decent foundation for implementing shaders.

The age-old argument.

Lately I’ve been working on abstracting Direct3D and OpenGL. This wasn’t actually my intended goal - my intended goal was to write a renderer in Direct3D with shader support, but it just turned out that way. I do admit that I have been concentrating on the Direct3D half of the job more than the GL half: so much so that the OpenGL half no longer works. This doesn’t bother me much. I’m sure Luke will write a version in his beloved API if he has time.

Speaking of which I have always been a firm supporter of OpenGL, but I have found myself drawn to Direct3D more and more lately. I have always thought that Direct3D was a disgusting API (particularly because of the Hungarian notation) and that it was inferior to OpenGL. I see now how disillusioned I was: Direct3D is vastly superior. OpenGL is good for prototyping small applications that require no special features, I feel. Direct3D, though much more annoying to set up, is so much better for large applications in the long run. I spoke to Jim, a tech. lead at Climax Studios Solent about this a few days ago and he agreed whole-heartedly. Having much more industry experience than I it seemed rather obvious that he’d thought this since DirectX 6.

Direct3D’s shader support is vastly superior over OpenGL’s “afterthought” version, which is the only reason I chose to use this API in the first place. However, I now see that Direct3D is superior in nearly every other way too. It is not the nicest API to look at, but then I took a new look at OpenGL and realised that it’s just as disgusting, if not more.

Despite Luke and Daniel’s push for Direct3D in our projects, they still love OpenGL. Also, at the GDCE last year Keith Ditchburn (also see Toymaker), one of my lecturers, told me that industry people prefer good Direct3D knowledge than OpenGL knowledge. Jim from Climax seemed to agree, considering he interviews people for the Solent studio this counts for a lot. Speaking of which, he also recommended PS2 vector unit code and assembly, so I should look at those in the near future.

I’ve come a fair way in my Direct3D renderer. It’s nothing special - yet - but I have got swappable render targets with render to texture happening which I have never done before. In fact, with Direct3D it’s so easy I did it while drunk - no kidding. Though I will have to look back on it soon and ensure that it’s best way that I could do it. I’m beginning to get that dirty feeling that I get when the project I’m working on seems to be held together by blubblegum in places. I think my primary concern is the private implementation of the textures. I’ve actually repeated some code (ack!), and I’ve passed my IDirect3DDevice9 pointer to sub objects like textures and targets. I’m not sure this is a good idea, but in some ways it’s necessary. I doubt the speed and efficiency of the GetDevice() function in the Direct3D objects. I’ll have to look into that a bit more.

Oh, and finally: HA! The hilarity…