Life changing magazines #4

So this one is a little simpler. It's my first published work. I was 16 when I sent it off, so in the 2 years from reading the WORMS program listing, I had learnt basic Z80, gotten a spectrum, written a Database for my Mums work, was without a computer for a almost a year(spectrum went back to my mums work), and then gotten a Plus4 and learnt 6502. I find this frightning as these days, YEARS seem to slip by without anything appearingto happen!

So here is the letter I wrote, the reply I got, and the final article. I was well miffed that they didn't put my name on it however - everyone else got that! Story of my life that.... everyone's always taking credit for my work in some shape or form....

From now on, they're not that "life changing"... just important, or funny. There was one other one, but I appear to have lost that. It was a turbo loader for the Commodore Plus/4 which I used a lot, but I then adapted it to be an interrupt driven one on the C64, which then allowed me to play a game while things were loading. Aside from this one, the rest were all after I "turned pro", and so weren't important, just funny/cool/etc.

Life changing magazines #1

I guess every programmer has a genesis moment. One where everything starts to make sense and it's the true begining of their love of programming. This was mine. I was 14 and must have had my ZX81 for about 6 months or so when I bought this magazine. I was at my grans in reading this and suddenly all those HEX numbers I'd been typing in made sense. There in front of me was a true assembler listing. I suddenly realised what all the codes at the back of the manual meant, and how you used them. I poured over this article for days, playing with it, trying new values, changing little bits to see what would happen. Up until now I'd been doing ZX81 BASIC and was getting on okay. However when I got this article I saw the routine that drew the border and called it directly.

BANG!

Unlike Basic, it popped up instantly. I was gob-smacked! It was SO quick. Basic would have taken over second to print that much! I played around with it, changing the character it drew and so on.

This showed me just what computers were capable of, and how these games I bought actually managed to do what they did. Now I could see how it all worked, I started to learn it all...

Put it simply... this is what got me hooked.

Life changing magazines #3

So, I got this I think around 1985, second hand again. This was very cool though, it showed how to make your own turbo loader! Now I still didn't really understand it at this point, but I was able (with the aid of an amazing tape deck) to make a screen grab load at an amazing 6,000 baud! This is microdrive speed; from a NORMAL tapedeck! It just blasted in! I was also able to load data in via a slightly odd pattern so the screen would come in backwards, and even from both directions at once! Normal spectrum turbos were 3,000Baud (with the original ROM routine at 1,500), so I had great fun fiddling with these routines.

I've still to track down the No.1 magazine. I do still have it, but I've no idea where!

Life changing magazines #2

Yes I know... I'm starting at #2, I need to track down the No.1 magazine. So this one was published when I was just 13, and it had the key equations for doing very basic 3D and perspective. I used these equations for years before real full matrices were possible, but it still holds a special place in my heart. And yes... theres a chunk missing from it. I got it 2nd hand, and someone had sent off for something ripping a big bit out of the article. Fortunately, it wasn't important as I didn't really care about the program, just the method and equations.

ZZap64!

I've just received my original Oli Frey ZZap64 artwork! And I'm pleased as punch! It's from issue 9 of ZZap64 and it's a beauty! It's actually draw at the original size (or very close) to that of the magazine, which I'm astounded at! Normally artists will draw x2 or larger so they can get the detail in, but he hasn't! How the hell did he do that! The detail is amazing on it. I've also discovered I have that magazine, so I'll now get them framed together and it'll take pride of place in my workroom.

I can't wait to see what other ones he'll put up for sale, who would have thought all those years ago I could own an original! Very cool....

You can go buy your very own original at the ZZap superstore: CLICK HERE!

(must now stop using exclamation marks to end every sentence...!)

KISS - Keep it simple, stupid.

I'm a big fan of simple code, probably because anything more complex confuses me and I'll never understand it. This is a hard lesson which I learnt when I was about 15 or 16. I had written a very clever platform routine in assembly on the spectrum. It would draw a Manic Miner level using likes and some king of direction control. However, it was so clever, that after I had written it, debugged it and it was fully working - I had NO idea how it worked. Not a clue. Now, I'll cut myself a little slack here... I was only 15 or so, and had hadn't been doing assembler that long really. Still, I had written it, so I should have understood it! Since then, I've followed the KISS philosophy. Keep it Simple, Stupid. Although the original was apparently Keep it simple and stupid, I prefer the newer interpretation, as you really don't have to be clever to be an engineer these days (particularly a software engineer), and we love to complicate things; so I prefer the insult. If you haven't kept it simple, then you're stupid.

I see this everyday at work, coders who think the latest shiny blog posting about some cool new method is the absolute BEST way to code, and anyone that doesn't is mad! MAD I TELL YA! Well, thats obviously rubbish. If you follow every posting by some new publicity hound, then you're codes going to be terrible, plain and simple. The only real rules for coding is that its got to be clean, readable, fast (enough), maintainable and extendable.

Outside of these simple guidelines, nothing else matters, and it's simple a personal choice. You can throw other things into this mix, like testable, abstracted etc. but these can cloud the code to the extent that its none of the things it should be. I've see code thats been abstracted so much, it's beither readable, fast, maintainable OR extendable. A little abstraction is a good thing, but only when you need it. If you're writing a bit of code for windows, and it's never gonna be moved onto any other platform, then why abstract windows calls? If your going to add value to them (but having them do more, or make the API easier), then thats fine. But never add layers for the sake of them. You should never end up with an API that just passes things through directly unless theres a damn good reason (moving platform it a good reason, as you're wanting to hide the underlying OS calls).

However, desire for coders (especially a novice/junior) to complicate things is pretty high, as is the desire to make a perfect API. Take it from me, thats an impossible dream. You might think it's great, but others will always want something different. The idea is to make an API as good as you can right now, and adapt as time goes on. In the world of professional development, it's all about getting products out the door, not going back over API's trying to make them absolutely perfect. They have to perform the job, and do so with an API that was as good as you could make at the time, otherwise, you'll simply never finish and go bust.

In the end, there's 2 types of coders.... Those that want to get things done and out the door (and this doesn't automatically mean bad code!), and those that want to polish things and write docs, and make things pretty, but ultimately cost you dearly.

Oh...and if you've never seen the second kind, then your one of them!

Designing a good API

So I've been doing some work porting some code to another platform (which I'll speak about later), and it's showing a severe lack of API design. Now I design APIs for a living I thought I'd quickly go over what I think makes a good API, not just from a users point ov view, but internally as well.

Simple and Fast. And we're done. Thanks for reading.

Okay... I'll go into a litte more detail. Now, API's are usually there to give a coder simple access to a more complex system. Take DirectX. The underlying hardware and systems are pretty complex these days, what with interrups, DMA chains dynamic memory management and all the rest of it, yet the API is (reasonably) simple. So... here goes.

Simple. An API must be simple, in fact as simple as you can get away with. This isn't to say you should make it basic, no. You should make it do everything a coder will normally have to do, but don't over complicate it by using 1,000,000 calls for each function. Take DirectX texture creation... Now, whenever I do a graphics engine I have a single CreateTexture() function where as DirectX has several. Textures, Surfaces, DepthBuffers and Cube Maps, the list goes on. Now why? Theres really no reason for that kind of split. You could just as easily use flags and paramaters to allow the various types of selection. This means the coder only has a single function to learn, and if you follow this kind of rule for the whole API, then the entire system becomes much smaller. After all, would you rather a 1,000 call API where you have to set the width and height of a texture indavidually, or 10 functions that can do everything! The smaller the API, the more control you can keep over it. If you give access to every single function and variable, then it becomes a nightmare to change or upgrade.

So, keep an API simple. It's less to maintain, and the programmers that use it will thank you for it.

Speed. This is obvious. It has to be fast. If your management code gets in the way, then the API will become too expensive for coders to use properly, and they'll end up writing support functions themselves. This is really bad. You want the programer to have confidence in the API, not only that it'll do what you say it'll do, but that it won't slow him down. Streamline as much as possible, remove as many if's and but's as you can inside performance critical areas.

Now, a quick word about abstraction. It's important to abstract certain types of API so that it's clean and portable. Now theres a few of reasons for that. First you expect the API to change under you. If your using some open source interface, you never know when the latest buzz word is gonna take hold and your whole API is gonna change, so a simple layer of abstraction will protect you. Next, it will allow you to add value to an underlying API. Take DirectX texture management, if you add a simple layer to your API, you could then now keep track of all your textures, and it'll allow your to manage things like device resets (when you resize the window etc.) as since you own all the texture pointers you can free/reallocate things like render targets automatically. Lastly... Portability. Now most hobby projects don't care about this, but you never know when your project might take off and someone else might want to port it for you to a Mac, or a ZX81...or something.

The program I'm currently working on was hard coded for windows, using not only MFC, but DirectX calls and enums directly. So, being someone that designs APIs, I know all about abstraction. Being someone who's worked on lots of multi-platform games, I know all about how to make an API platform independent. So, thats what I'm doing. All calls to DirectX and being put through a layer of abstraction, each ENUM is being changed to be platform agnostic. This means the API can translate (very quickly) to whatever rendering API I want, without the main application knowing, or caring. The classic case is DirectX and OpenGL. Doing this would allow this program to run on the Mac, without the main program changing. I'd only have to port the (now pretty small) API, and not the whole program.

If you've done your job correctly, you'll have to port a handful of API's. Sound, Graphics, Networking and simples file systems and memory management. All games can be based on these simple API's, and then be made to run on other platforms (reasonably) easily.

Theres obviously lots of ideas for each API. Designing graphics APIs is an art in itself. I've used the same API for the last 10 years. The underlying graphics systems have been PS2, XBox 1, DirectX 8&9 and I know it would work just as well on a PS1, XBox360 (never seen a Ps3 SDK), and DX10/11. A well designed API will work on any platform and be a pleasure to use.

So there you go... Keep an API simple - don't get sucked into the latest fad. Keep if as fast as you possibly can. And abstract to reasonably protect yourself from underlying systems and to allow simple porting.

The good, the bad, the ugly.

I've currently been looking at another code base at work and it's brought to light something I've known for a while, but which is now front and center. Not all programmers are good programmers. It's something which is pretty obvious, but what isn't obvious is the split. You would like to think that it's a pretty linear grade with even numbers of coders at each level, but in fact it's pretty biased towards the lower end and the numbers drop off quickly the higher you go.

Now the games industry is pretty hard to get into in the first place, so truly bad coders in our industry are exceptionally rare. Thats not to say we don't get them (and I think we have a couple in our company to be sure!), but most of our problems are due to the lack of training. We have a heap of juniors on our project and they just haven't been mentored correctly. Now for the most part they're all pretty good (or they wouldn't be there), but without proper mentoring they'll just do it their own way, and not the way they should. Training, and experience is everything, and while it's far easier to churn out decent looking games due to the sheer power of modern hardware, thats not to say that the underlying code couldn't, no shouldn't be far better.

This is much more important than you'd think. In the past you'd write a game and as soon as your finished, you'd hardly ever look at the code base again. That just doesn't happen these days. For starters, engines and tool sets take time to write, so you have to look after them and use them as often as possible. Second, sequals are very common and the turn around on them is usaully very tight, so having a solid codebase to start from is important which means you can't just fudge your game and forget about it. Companies are made on their I.P. and your codebase is a vital part. This means you have to not only value your staff, but make sure you train them as best you can, and I think the games industry as a whole fails in this.

Time marches on...

Wow... what can I say... WOW! As of the 1st of August I've been in the games industry for 20 years. 20 YEARS!! Who would have thought it. My mum said it was a waste of time and I would never amount to anything (okay, she was still right but..), and back then it was such a bedroom industry that you almost knew everyone that ever coded a game. These days, I've never heard of any of them!

*sigh* happy days. We has some great times at DMA, the early days being by far the best - it was just so much fun back then! Thats not to say some of the later days weren't good too, but hardware is just so boring these days - powerful, but boring. Just about anyone and his dog can make a reasonable game now, and that takes away much of the art that you needed to do really cool things.

I did a little test at work recently and was able to draw 1,000,000 lemmings faster than we could draw 100 on the Amiga. 1,000,000!!! That covers a 1280x1024 screen 195 times over!! or to put it another way, imagine a SNES with 3,900 parallax playfields, and STILL have enough grunt to draw 1,600 sprites! Amazing power. But what do we do with it? CPU's are now so powerful, it's like having over 500 SNES per CPU - and I have 4 cores on my machine!

So much has changed, and a little of the fun has gone. Now and then you get some of it back, a little bit of fun optimisation still brings a tear to eye as you remember the fun you used to have pouring over a few lines of assembler while trying to get a single cycle off. I sit and watch all these new boys, and shudder at the waste in their coding, memory, cpu power, disk space, network bandwidth... all of it. They don't seem to spend as much time thinking about these things as we old timers do, and the sad thing is, they probably don't have to. Sure a little more care would work wonders, but CPU's are actually made to help average coders. Thats a sad fact of life, the world is full of average or less than average coders, so all the clever folk at Intel, AMD, ARM all work away to make things run faster for them. but this leaves the few of us left struggling to find the fun we lost.

Still, it's not all bad. Some new hardware is always around the corner, and your mobile phone is now more powerful than even the old consoles. Look at the iPhone. Really nice bit of kit, and fun to code for. Languages have changed too, and I've (almost) given up assembler for the likes of C# as it's just faster to work in. I've had some hard leassons to learn here though, giving up memory management is still a sore point but it does make life simpler for most tasks, but I really miss knowing where every byte of my program has gone.

It's sad I guess. I'm a man stuck in the past. On the one hand, I'm trying to hold on to the fun I had in the very first days of coding, while on the other, I try to use all this new power as best I can, and teach these new boys thing or two while I'm at it. It's now all about bridging my experiance, learning from the past to bring forward old ideas and use them in new contexts.


So will I be here in another 20 years? Who knows... I suspect I'll still be coding in some shape or form. It still has the same lure as it did when I first sat down in front of a ZX81 and black and white portable TV as a 13 year all those moons ago. But what will change in the next 20 years? or even the next 10? More CPU cores I guess, bigger badder machines, easier to program and just perhaps, a little more fun.

Lets hope...



Anyway, heres some of my career highlights I've enjoyed...

• 1989 - Ballistix is released - My first game!
  
• 1990 - Blood Money on the C64 is released.
  
• 1991 - Lemmings
  
• 1994 - Lemmings 2 SNES
  
• 1994 - Uniracers
  
• 1995 - Writing various prototypes and trying out several game ideas.
  
• 1996 - Minus4, my first emulator!
  
• 1997 - GTA, particually the 3Dfx version.
  
• 1999 - GTA 2
  
• 1999 - I left DMA and moved to Visual Sciences at Head of Reasearch and Development.
  
• 1999 - XeO3, a small on going project begins...(still not finished!)
  
• 2000 - Internal debugger for the PS1 based on an Action replay, along with some fun on the PS2.
  
• 2000 - F1 2000 on the PS1
  
• 2001 - F1 2001 on the XBOX
  
• 2001 - I left Visual Sciences and moved to Simian Industries as Technical Manager.
  
• 2005 - Moved to Realtime Worlds after Simian went poop to prototype some ideas.
  
• 2005 - Various tech demos for an undisclosed project.
  
• 2006 - Russ joined me at RTW and my project team doubled in size.
  
• 2006 - Actually started to use C# in anger.
  
• 2006 - Huge scale tech demo. Great fun.
  
• 2008 - Rewrite and an even bigger scale demo - pretty cool.
  

Delphi conversion

So, I'm doing a little Delphi conversion just now and while looking through the code I came over a little bit which didn't quite make sense. Rounding floating point numbers into integers. Now my default has always been to truncate for rounding. Not only is it faster (by far!) but it's easy to predict, and everyone understands it. Now, Delphi's rounding...wow... it's nuts!

Dephi seem to have gone out of their way to complicate things, and I can't figure out why. Anyway, after doing a quick search heres the Delphi rules...

The Round function rounds a floating point Number to an Integer value.
The rounding uses Bankers rules, where an exact half value causes a rounding to an even number:

12.4 rounds to 12
12.5 rounds to 12 // Round down to even
12.6 rounds to 13

13.4 rounds to 13
13.5 rounds to 14 // Round up to even
13.6 rounds to 14

Now...why o WHY would you do that.... Round .5 to EVEN! What! Nuts I tellz ya...

Editor woes

You know its amazing how fast you can do an editor if your not trying to be fancy. Take RetroEdit. It's actually trying too hard to be the jack of all trades, and as a result, its currently the jack of none. This isn't to say it won't eventually work and do its job, but currently because its trying to hard, its progressing slowly.

Now, take a look at a little map editor I'm currently knocking up for my little iPhone Golf game. I'm not trying to make it a generic editor, and I dont want to reuse it later (not that I couldn't hack it into something else later mind). But this means Im free to throw code in at a great rate of knots and as a result, within a day (almost) I've just about finished the basic editor. It's got a tile window, brush support (grabing multiple tiles at once), and I'll add a quick UNDO function in there for when Im being stupid.

It's amazing how quick you can do these things when your being specific, and I do wonder sometimes if the tools I try and do at home are being too ambitious and as a result might never get finished... hay-ho...

iPhone fun...

Yeah, I know... long time again. I've started doing some iPhone coding to see if I can actually finish a (proper) game at home. Doing games programming at work, then games programming at home is hard going. Doing the same thing all day, then coming back home and doing it all again is a little soul destroying. However, I'd like to try and give it another go, and who knows.... perhaps make a little cash on the side.

So, XeO3 will (yet again) take a back seat for a while so I can see if I can make a real go of this stuff.

On the plus side, I've been doing some OpenGL at work, and it's putting me in good stead for doing some at home! I now know a reasonable amount about it so should be able to use the iPhone's OpenGL ES reasonably easily..

Well, here goes nothing....

Reporting In...

Nothing much to report. I've just had a nice relaxing birthday weekend and done nothing but cut the grass and watch the Monaco GP. Great fun. However, I have gotten my subversion server up and running again, so that at least should be backup for everyone using it.

No idea when I'll get back to doing stuff, just not in the mood just now - not to mention still installing stuff for windows 7.

Still, had a great weekend so what the hell :)

Subversion

I've now reinstalled sub-version. As I'd hoped, it was pretty painless since I already had all the config files setup and simply had to point at them. Windows 7 is pretty nice and I'm trying really hard to keep features like the user account control, but I'd also love to be able to switch it off for specific programs - like the command prompt (when run as administrator). Still, I'll keep plodding on and see if I can get used to it.

I'll need to test the remote access tomorrow, but since the firewall hasn't changed, it should all be fine; fingers crossed!

I've only a couple more programs to install and I should be back to normal. I have lost my 3rd monitor as it the display seemed to be locking up a lot, but since I've just installed some new drivers, I'll try switching it back on and seeing if its all working again. I like having 3 monitors, it'd be a shame to lose it.

Russell reminded me that I actually have a proper MAC that I could be testing with MONO (my dual core G5), and although I'll need to get more RAM it would be a good testing ground for retro edit (which Russ tells me runs pretty slowly on it) and mu debugger - once I get TCP/IP support in. I could probably knock up a GL version of Minus 4, this should be easy as Russ has ported my speccy emulator over I suspect I could pinch the source to that and get Minus4 working pretty quickly. This would then let me use the OgreDebug and the TCP link to the emultor.. I think.

Windows 7!

I've just installed the windows 7 release candidate and it's all very nice. It has some issues with my 2nd graphics card (I use a small PCI card so I get a 3rd monitor), but aside from that many of the annoying vista-isms are now gone.
However... Because it's a clean install I now need to reinstall everything, including the sub-version server but I hope that since I'm just pointing at a depo it won't take too long this time. If I get a chance tonight I'll try and finish installing everything, then I can (I hope) plod on with more interesting things.

InpOut32.dll

Yes!!! Not only have I got it working again, but they have managed to get SIGNED drivers! This means I no longer have to boot up pressing F8 and booting into unsafe driver mode. This is awesome! It also means I can carry on with my debugger and try to get it to a point that I can add the TCP/IP (or UDP) mode.

For those that are interested, full signed drivers (for my upload program for example) can be found HERE

I'm very happy!

Source control...

I've finally (FINALLY!) gotten my subversion server up and running and even managed to open up access to other members of the team. This means Russell can now help out on the editor and debugger (if he gets bored), and once Luca gets used to it, he could actually build levels directly into the source without me having to make special versions for him.

I'm currently adding all my relivent projects into the depo and assigning various access rights but it all appears to be going well. Russell has been busy moving house so we're hoping that he'll actually start doing things again soon! (*gasp*)
(perhaps he'll even update his blog!)

I've been trying to get my debugger up and running againas it's quite close to a first version (I think), but there seems to be an issue with downloading to my plus4 - no idea why. I just hope my parallel port isn't fried again! I weas toying with doing an RR-Net for the plus4, and if my parallel port is dead, I may have no choice. I guess I could always do a C64 version in the meantime, and I still have the emulator plug-in to write as well.

I really need to get back up and running as I'm currently not getting anything done at home just now. Fingers crossed this will change soon!

New video...

I've uploaded a small video showing the current state of the C64 version. I suddenly realised I'd been sitting on it for ages and no one had really seen it.

You'll notice its not quite right, as background stuff isn't animating, and bullets aren't quite right. Still, it looks pretty, and the multiplexor holds up pretty well too!

To API or not to API... THAT is the question....

I was reading an old post on a form from Tim Sweeney about how all graphics cards will go the way of the dodo, and how no one will be able to write an engine and they'll all have to buy his. He was claiming (back in 2007) that the GPU will become extict abd we'll just be left with massively parallel CPU's that do everything, and that API's like DirectX or OpenGL won't be needed because everyone will simply code their own engine.....

wow.... while a pile of crap. While things are heading towards being able to do more and more with a GPU - or many CPU's like intel's larrabee, the API won't ever become extinct and theres a damn fine reason for that. Developers simply dont have the time to make the huge number of features that directX (or openGL) already has. Who really wants to write full perspective correct, tri-linear, multi-texture stage texture mappers? Not to mention that it'll probably only work on a single platform and you'll have to do it all again. Nope, its total rubbish. Whith will probably happen, is that DX/OGL will continue to deal with new graphics cards and tech and allow game developers to carry on writing games without having to worry about all the low level crap, while a (very) few middleware folk decide to implement their own custom code. It may well even be that normal developers use DX23 for most of the normal stuff, but then implement a really cool voxel rendering system to do some special features.

This makes sense, of course it does. DirectX/OpenGL aren't just about drawing triangle, they're about taking some of the development cost away from developers and allowing their code to run on almost any hardware without any real code change. For those that remember the good-old-days where you had to write versions for every card out there, you'll shudder at the thought that it'll return. I did my fair share of software/DirectX/Glide/PowerVR/S3 ports and it was horrible. True I prefered Glide as it was about 3 times the speed of DirectX, but graphics cards are fast today, and it doesn't take a coding god to make a pretty looking game. In fact most games these days are written by what I'd call normal programmers. Folk that don't really know what the hardwares doing, but its going fast enough so why should I care - that time. And thats fine, it means the games industry grows, you can let normal coders in, its easier to find people and the world is a happier place.

I also find it ammusing that Tim seems to thing API's like DX will go away. The only platform in the world without an API are old systems like the SNES/Megadrive etc. (and older). Everything else you have an underlying OS with...wait for it... an API!!

Theres always gonna be an API, and interfaces like DX and open GL will simply evolve to meet the demands of the programmer - whatever that is. It'll implement common features so we don't have to, and only if your really interested (and think you can do better) will you have to write you own VERY low level bit of code.

I can't wait for larrabee, not from a graphics point of view, but for the ability to run normal code on it. I really don't want to have to write another 100 triangle rasterisers for a single game because I can make each a cycle per pixel faster.... machines are fast enough to not worry too much about that, and if the Wii has proved anything, its pretty graphics isn't what makes a great game - Mr Sweeney should really buy one have have a look.

DO.EXE V1.2

okay.... VERY quick update. I've quickly added C/C++ hex support. So now you can specify HEX numbers as 0x186abb etc. I meant to do this ages ago but never got round to it, and since the solution file was still open this morning, I've quickly added it. Find it in the same place as before....


http://www.javalemmings.com/blog/do.zip

DO.EXE V1.1

I've fixed a minor bug in my DO.EXE program. It wasn't recognising lower case "c", only the uppercase one. This made entering HEX very annoying. If you use it, get the new one here. Its in C# (.NET) so is cross-platform ready using mono.

http://www.javalemmings.com/blog/do.zip

C# JIT

I was speaking the other day about the C# JIT and how it sucks sometimes... well, heres some real code to prove the point...

            m_ArrayAccess[0].m_Pos.Y = 2.0f;
00000022  lea         edx,[ecx+8] 
00000025  cmp         byte ptr [edx],al 
00000027  mov         dword ptr [edx+4],40000000h 
            m_ArrayAccess[0].m_Pos.Z = 3.0f;
0000002e  lea         edx,[ecx+8] 
00000031  cmp         ecx,dword ptr [edx] 
00000033  cmp         byte ptr [edx],al 
00000035  mov         dword ptr [edx+8],40400000h 
            m_ArrayAccess[0].m_Pos.W = 4.25f;
0000003c  lea         edx,[ecx+8] 
0000003f  cmp         ecx,dword ptr [edx] 
00000041  cmp         byte ptr [edx],al 
00000043  mov         dword ptr [edx+0Ch],40880000h 

As you can see it not only continually reloads the base address of the array+type, but appears to insert pointless CMP instructions all over the place. The only reason I can figure for this is to attempt to prefetch the destination; however since its about to access it on the next instruction, this is pointless - Not only that but since its sequential chances are its in the cache alrady! And even is by some mirricle that it DID matter, why the hell is it doing it TWICE!!!



Man I find that annoying....

More C# woes....

The more I look into C# the more I wonder how it manages to run as fast as it does. Even the simplest things it appears to double up on code, put in random meaningless opcodes etc. For example a simpel series of load/store operators like below resolves itself into a reasonable ugly mess of asm...

   Vector.X = InVec.X;
   Vector.Y = InVec.Y;
   Vector.Z = InVec.Z;

The problem is that it simply can't track registers properly and that means it has to continually reload the base address of the object which ends up making the code twice the size.

It also insists on loading then storing floats even though its just transfering bits. You can obviously just use integer registers to transfer data and this could pipline much better than series of FPU load/stores. It's frustrating as if this was C++ I could just drop to ASM and do it myself, but in managed code your at the mercy of the JIT.

Now the JIT gets better each itteration but it doesn't appear to get better where it counts sometimes. For normal code, this simply doesn't matter, you lose around 5-10% speed max. But for code that needs to be highly optimal, this can be a real issue.

C# and Ants

Since it's been a little while I thought I'd tell you what I've been up to lately at home and work. I've been playing with ANT4.0 which is a profiling tool for C# (and .NET in general). The last one was pretty good but had some issues, while the new one is excellent. Profilers can always get better but the leap from the last version is pretty huge. For a start profiling is almost realtime which is very impressive, normally apps crawl when they're being profiled. You can also play with results while the application is running, which is damn impressive!

I bought ANTS3.0 last year and its pretty expensive but I thought that since I do lots of C# at home I would get the use out of it... trouble is, the stuff I do at home simply doesn't need profiled! Not that V4.0 is here I dont really want to spend huge sums of cash on it again, bnut its such a nice app I'm a little torn... Oh well.

Anyway, I've been profiling some of my work and doing some optimisation at home. It's actually been years since I've done any serious optimising and I'm having a bit of fun with it. C# is pretty cool in that you can do real managed code, or unsafe C++ style code if you really want to. When you're optimising you tend to fall back to unmanaged code as its still quicker.

We've also been getting some little shocks at work as some of the C# collections just aren't as quick or optimal as we were expecting, this has meant we've been starting to write our own set just to make sure its doing what we think it should be doing. Games programmers are funny like that, we hate slow code and will happily sacrifce readability for speed (within reason of course). Anyhooo.. I'm having a blast playing with peep-hole optimising, although its hard to say how this will affect the app overall just now, but I'm pretty happy with the main loop now as its very tight.

It reminds me that optimising is great fun, and thats why I got into games in the first place!!

SubVersion.

I've been trying to set this up again, but this time using Apache (since I have that installed anyway!). I've almost got it going, but for some reason apache can't see the repository. Its there, and the DOS commands can access it, but apache can't - must be something simple. Anyway, the reason behind this is because Russ has set it up on his machine and we reckon we can get it to share repositories so that I have a full copy of the history etc. Anyways, once I have it running Russ can start to help with the editor and the debugger and add features for the spectrum as he needs to. Once its running that is....

I've also finally gotten C# to give me the cursor keys! It's a bit of a hack to do it, but I finally managed to get a key up/down for them. This means I should be able to do cursor key movement in RetroEdit so you don't have to use the mouse. I didn't think this was important until I tried to use it on my laptop which only has those stupid PADs, it then became obvious that cursor key movement would be great! So I've spent a couple of hours trying to get C# to actually deliver cursor key inputs, and man was it yucky.... Still all done now, so I can now do the work to move around with them tonight.

Edit: Test....

Tick tock....

Been a little bit since I did an update, so here goes. I've been busy playing games (of all things) so haven't done as much as I should have, but I am still making slow progress on RetroEdit. I picked an older game called The Witchers, a very pretty RPG. Now I'm not a huge RPG fan, but I do love games like Diablo which have small amounts of RPG goodness in them, and this is in a similar vain, so I've been having great fun with it. Theres a little too much running around, but it's pretty good fun all the same.

Anyway... I've added inserting, deleting and cloning of frames which means we are almost at a usable state, but before I get to use it I still need to add colour picking and project loading and saving. I've decided to use the good old IFF to store all my data as it means I can add new features without losing too much data if I ever need to upgrade. So I'm writing (another) IFF file processor that lets me load/save IFF files easily, and putting it in the RetroBitmap control which allows others access to it if they like.

Once I have these 4 things added (and it all going well it shouldn't take too long), I'll try and get Luca to test it - although he's been in hiding reciently, but if he resurfaces he can take it for a spin and we can get on with some real features instead of the core editing stuff.

I did start looking at Onion Skining, and its a little more complex than I wanted as the retro bitmap control would need multiple sets of data to render it itself. This means I need to add a fairly large command that can render any format the control can and then return the image for Onion Skining. It's a little bit of a fudge, but oh well...

RetroEdit small steps.

I've had a little bit of a problem with a virus I think, but have managed to revert things by rolling back a few days. This however has screwed with my source files - even though it said it wouldn't. Oh well...

I've finally managed to get the colour palette into retro edit so I'll need to do colour selection next. It's a little flickery though but I'll deal with that later, as long as it's working just now I don't really care. It's feeling a little sluggish on my machine so I may be doing something wrong, but I'll need to try it on someone elses PC first. I have the feeling its drawing WAY too often. I'm happy to say though that its finally making some headway and I hope to deposit the first version into Luca's lap soon. I'll need to get loading/saving into it first so I'll do that after colour picking/selection has been added.

You'll also notice its missing sprite sizes, I'll add this later as well - it shouldn't be too hard - although I'll need to save differently for each platform. Currently these are Plus4 (MCM/Hires) C64 (MCM/Hires) and Spectrum. I'll probably add CPC down the line - along with anyother computer/console I play with.

Small Basic.

For those who don't know, Microsoft development labs has released a new language called Small Basic. This is aimed squarely at the beginner. Do you remember how you started to program? Well, if your an old git like me it would have been on and old 8bit machine like the zx81, spectrum, Vic20 or Commodore 64 (or some other old 8-bit thing). The reason these machines were so cool to program with is that they were just so simple. Switch on and start. Basic was built right in and anyone could start and learn it.

Well, a chap at Microsoft called Vijaye Raji has started a personal little project that one day he hopes will be included with windows - like QBasic was with DOS. This is an amazingly good idea, and one I had quite a while back as well (see here), but typically never got very far with. He however is getting on pretty well and has now released a really nice little development environment that while a little buggy, is looking very cool indeed.

Theres an interviewwith him on Microsofts channel 9 which is well worth watching. This is something I'll be keeping an eye on and might even write a little something for in the future. Its very cool.

Home again....

After my trip down to Warrington where I was able to take a side trip to Birmingham and get to the Commodore Computer Club meet it's good to be back home. I've decided an hour and a half is about as much as Im prepared to drive for a meet, and more and its a bit of a killer. This kinda rules out any others unless I happen to be in the area (like this time), or its particually large and I'm willing to stay for a couple of days; I'm getting too old for this shit... It was nice to be able to meet folk I'd been speaking to though, and gettting some faces to go with the names is great.

It's also the first time I've used my new iPhone for mobile web, and the map applications are fab. Asking for directions, or distances from where you are is a great thing to have on you. Safari was a little slow under 3G, but it worked and help pass the time at motorway service stations. However the battery life isn't wonderful so I kept feeling like I needed to switch it off. I'll need to see if I can find the PSU for it as being able to plug it into a wall to charge would have helped - if I'd but thought that far ahead....

I hope to do a little retro edit tonight, but I'm pretty pooped after the drive up, so lets wait and see....

RetroEdit to-do list

So, heres my current to-do list. I'll update THIS blog entry as I change things, so you can always check back here to see where I am. I'll add a link on the right for easy access.

Paint with colour 1 (left mouse)

Paint with colour 2 (right mouse)

+/- to change frames

rotate frame (up,down,left,right)

rotate line

rotate column

Colour selection

Colour Changing

Cursor rendering

Cursor key movement or cursor

Copy frame

Insert frame

Delete frame

Colour Swap

Area selection

Copy

Paste

Brush paste (like a sprite, drops out the background colour)

Mirror

Flip

Save project

Save data (native format)

Load Project

Load data (native format)

Onion skinning

undo/redo

Remember to check back here to see how I'm getting on.

RetroEdit.

I've not been doing much past few days/weeks. With the flu over Christmas and now a cold I've not really been in the mood. However, I've decided to make an effort and have started back on RetroEdit.

I've finished the refactoring of it an am now happy with its layout and internal code construction. Basically, the old control I was writing delt with retro graphics in an abstracted way, and so you had to do some work to use it, now however the control deals directly with the raw format which means all you need to do is copy actual retro graphics data into the control and your all set.

So with this done, I've started to plow ahead with some features. Actual editing is obviously first, and I can now draw pixels with the mouse in both hires and multi colour modes. This is also true for C64 and spectrum editing. I've also put in sprite rotate left and right, and am about to do up/down.

Once I've done this I'll add colour picking. Currently I have 2 default colours and you can't change them - this obviously has to change to be of any use, and as its a biggie, I'll do that next.

I'm sure I listed these before, but it must have been ages ago so here it is again; the feature list I want in for version 1.

Paint with colour 1 (left mouse)

Paint with colour 2 (right mouse)

+/- to change frames

rotate frame (up,down,left,right)

rotate line

rotate column

Colour selection,

Colour Changing,

Copy frame

Insert frame

delete frame

Colour Swap

Copy

Paste (+background)

Brush paste (like a sprite)

Mirror (+around selection only)

Flip (+around selection only)

Save project

Save data (native format)

Load Project

Load data (native format)

If theres anything else that you think is a must have, then let me know. I've no idea how long this will take me, but the sooner the better. Currently it lets you edit Plus4, C64 and Spectrum sprites although I still have to put real support for the C64 sprites.

Powering up.....

Because I was ill over Christmas, it's actually been a while since I did any real work at home. So I thought I'd make an effort to get over this and actually DO something!

To this end I've resumed the refactoring of RetroEdit and decided to get editing actually working and usable. So now that I think I've actually finished the refactor I was wanting, I've started to write the editing features. I've currently got hires sprites being editing, so I'm about to try MultiColour Mode ones. I'll then do some basic features like scrolling the whole thing around the window, flip etc. then move onto colour editing.

I need to get the selected machine's palette drawn so I can pick colours and then I need to tackle saving. I'll need a PROJECT save, and a binary save. I'll also need to allow plugins so that folk like Russell can save formats he wants to deal with; although he may well end up doing his own editor, but others might need it so...

With a bit of luck, most of these shouldn't take very long, and I can take the core of the sprite editing and move it to the character editing tab. The core concept of this is a special RetroBitmap control. This allows you to deal with retro graphics directly without having to write huge chunks of code over and over - its also a standard control so others could use it in their own projects if they wanted to.

Back to normal?

Well, not quite.... I've just gotten my new cable modem installed which has boosted my speed to an increadible 50mb/s!! I've also just discovered that my trusty Linksys router can't keep up, so I'll have to retire it and get a faster one, other wise I'm stuck to around half speed - damn.

So, I need to put my room back in order (theres upturned desks and what-not) then I can setup the plus4 again and start to get back to work. I've been thinking about my electronics again, and I really want to get back to doing some more - before I forget it all, and this lead me to thinking about doing a better download system. You see, as it stands I need a parallel cable/port and thats limiting - particually since I have to switch my machine off/on to enable the driver and plug in the C64 or Plus4. So I was thinking about a USB cable. Theres a few USB to serial cables, and if I did that (along with a PIC or something at the other end), I could pretend its normal parallel cable on the Plus4 side, but do serial on the PC side. This would also mean it was suddenly hot plugable, and allow me to plugin multiple machines at once; not to mention being able to download without rebooting.

So, I may start to look at that kind of thing this year too.

DO.EXE

So... one of the big issues I had with upgrading to Vista64 is that a lot of my ( really, REALLY ) old tools stopped working. Now most I can actually do without, but theres one that I've actually been running under DOSBOX to keep. DO.EXE is a simple programmers calculator that I wrote back in the Shadow of the Beast days and does proper programmer calculations. That is it deals with HEX and BINARY as you'd expect, but also does AND, OR, XOR, NOT, Shifts and all the rest of it. In fact, I use it a lot just to convert numbers from BINARY to HEX since C/C++/C# doesn't take binary (its a crime I tells ya!). The old program was written in Turbo Pascal 7 and was very 16bit, and while I had the source there was no way I was gonna "update it".

Well, every since I started my debugger in C#, I had a brand new evaluator doing exactly the same thing, but in a processor (and machine!) nutral langauge! So I've finally pull out my logic prob, and blasted its little binary brains all over the back wall and updated it. Now, I know theres a million similar little programs out there, but I like the command line one, and I like that it takes the same format as C/C++/C# and even Java, and since I've always got a command line open, its ideal. CALC (and others like it) have just never cut it for me.

Anyway... I thought I'd be nice and release this into the wild and let others play with it. Its not hugely tested (so feel free to let me know any issues) but its an invaluable tool. Even simple things like getting bit patterns into HEX is a simple case of just typing it in.

Anyway...enough drivel...You can get it HERE. Shove it into your path somewhere then just type "do" on the command line for options. If theres any doubt in an expression, use brackets. I've not listed any expression order because it's different from all other compilers and that forces you to use brackets more to make sure the answers right. If theres anything else you think folk would like added, feel free to suggest it.

I hope some of you get some use out of it. It's the single most used tool I've ever written - period!


http://www.javalemmings.com/blog/do.zip

Flu season...

Happy New Year - and all that jazz

I've not been doing much over the festive season, I've been stuck with the flu and feeling terrible. In the times I have been feeling up to it, I've actually been playing the the Hydra system I bought LAST year. I really do want to get back into doing electronics again, but to do so I need an easier way to make boards - or try and order some up and see how that goes. Etching them just didn't work fo me, so I'd rather try and more automatic way.

I've also been toying with the idea of a userport to USB connector for a more compatable downloader. Theres lots of USB to serial ports, and it wouldn't take much to change that into a pretend parallel connection for the Plus4 (and C64 etc.). So that would be nice. Also using the user port means I can keep the cartridge port free for more interesting things.