Thursday, May 25, 2006

Blah....

I've been feeling really crap past few days, full of the cold or flu - who knows. So after being off wortk for a couple of days then back in today, I've decided to take a long weekend to relax and try and recover a bit more, today was hard going and I didn't really get very far.

Russell seems to be having fun doing some visual effects for our app, and while not vital, they will show how dynamic it is and the advantages it holds. Theres still a long way to go, but with any luck the visual quality should double which would probably make it more attractive to the people Dave's after. Im still finishing off my GUI system, but its almost done. I took a small timeout to help Russell with my 3D engine, and correct and improve some of it. It appears to be using lots of VRam, but Im not really sure why - something I'll have to investigate.

I've not done anything with my BASIC really, been too knackered. I hope to pick it up again soon, although I intend to buy the kids climbing frame this weekend so thats probably a wait and see. Still, these things usually take time to deliver so...

Sunday, May 21, 2006

Google me this....

I've been playing with Google earth and Sketchup, and boy does it have issues. I mean, its nice being able to build your house and put it in google earth and all, but theres so many limitations to the editor that you just dont get with a normal 3D package. Initially, you think its much easier than a real 3D package, but as you get into an edit, you start to realise all the tools that have been removed, are actually ones you need. Its also dog slow, and I'm not really sure why. Being a games coder, Im used to throwing around 100,000's of polys, yet google earth stutters as it draws a few hundred. No idea why, particually since they do draw lots when you switch on buildings in New York. The comunity's seems a bit too wide spread as well, although they do have a good age spread. My father-in-law loves it for example, but I know that no one aisde from an artist could actually use sketchup. Oh well, I guess it might get better in time but there are still problems that the concept of using sketchup gives. But when you have almost infinite money, I guess those can be fixed too.

Wednesday, May 17, 2006

Work, Rest and Zzzzzzz

Boy am I tired. I think the heats starting to get to me. Every year I think, I know... I'll buy and Air-Con unit in the sales, and every year I forget. Oh well. Champions league final tonight, should be good.

I've been playing with doing a windowing system at work for my game, and was trying to find a nicer way doing things. In the past the systems been fairly simple, workable but not very expandable without editing the actual library code. So this time, I've set about trying to change that. Its workout out pretty good too, and now you can great your own buttons or gadgets and hook them into the system without the system having any idea on how it works. This is key to how everything in our interface needs to be. Totally expandable with simple code, and without changing the root codebase. Unlike Unreal for example where youre expected to change almost everything, here the idea is you change almost nothing, and expand it.

Monday, May 15, 2006

Relaxing....

Didn't do much this weekend, overdosed on watching Battlestar Galactica which was pretty good fun. Been thinging about how to debug a basic program and it gets fairly complicated when you start trying to step into functionts inside the middle of an expersion evaluation. For example if I try this i=1+Func(), then in order to step into a function I'd have to somehow store the whole evaluation process in a state machine or something.

An easy solution would be to not allow debugging through this, but its not very nice.

Friday, May 12, 2006

More 'o the same.....

I've been progressing with my BASIC interpretor slightly - as I thought, its slow going since I don't have a whole lot of time at night to actually do it. Still, at least its progressing.

I changed the way my token buffer works to allow multiple "basic" classes to have its own interface into the token buffer. This should allow multiple basic threads, which is fairly cool - even if it is just interpreted. I also added a token stack to allow items to be pushed back when they aren't needed. usually I only need a single item, but I added "N" depth just in case, although its yet to be tested.

Theres something odd with this code though, as Im having trouble following it a bit, which is usually a sign that its been over engineered an too complicated for its own good. So I'll have to take a step back and see what I've done wrong. I suspect I've just added a layer I don't need, or added it in the wrong place of course.

Currently I have the main program loop doing a pre-process, an then it calls ProcessTick() once "n" times a frame - or until its time allowed runs out. The Tick then in turn calls the TokenBuffer->GetNext() which fetches the next token and value/float/string if theres one attached. This is all very well, and fairly simple, which is why I'm wondering what I've done as it appears to be a bit more complicated that that.

Oh well... I must be doing something right at work, as I was playing with templates yesterday and did something Russell quite liked. This is pretty good as it shows I'm started to get the hang of it. STL gave me another kick in the teeth as theres another hidden option that lets you switch off range checking. I wish Microsoft would add a gamers switch that lets us go nice and quick, or at the very least TELL us about it! MS spend so much time telling us that games are really important to them, then ignore us completly when doing compilers and tools, it pisses me off no end.

Saturday, May 06, 2006

A Basic Begining...

So, I've started doing the basic interpreter and I've pulled in my old lexical analysis class. It dates back to when I was doing a 65816 assembler (for the SNES) on the Amiga, and its been ported and updated over the years. It lets me jump into the deep end on these kinds of projects, without having to write yet another lex processor.

So, this looks like it'll be fairly easy and fairly good fun. So I need to start thinking about how I want to handle stacked variables and procedure calls etc.The basic construction is simple a memory block with an overlayed stack system and this give me a call stack as well.

I've also been thinking on the graphics interface and the virtual screen/sprite system. I think having simple SPRITE, TILE and PLAYFIELD system should give everything you need to make some fun games. Kind of like BBC Basic on a SNES, which is a good goal to aim for I think.

Friday, May 05, 2006

Basic part III

I've been talking over the idea of doing a simple BASIC with Russell, and although he thinks I should compile to a virtual machine from the outset. I've never written a compiler before, but I think it'll take enough time to actually write the basic in the first place, so I dont want to start writing a compiler as well! The good thing about this kind of stuff is that you can easily add a cimpiler at a later date, so I think I'll stick with my original plan.

Which is....

  • Simple Basic langauge based on spectrum and BBC basic.

  • Multi-plane CharacterMap and Bitmap screens

  • Simple sprites of variable size

  • Simple sounds via WAV sounds (or similar)


  • With these basics, you should be able to construct most 2D games. I really don't want to get into 3D, as the idea is to let kids learn, and you don't learn much by jumping into the deep-end from day one.

    The best thing would probably be to pre-process the BASIC text file into tokens and then "run" them - kinda like the way old Sinclair Spectrum worked. This also lets me define global variables, procedures, and the main code.

    Russ and I decided to get Andrew to write a small game to help train him up. I suspect that he'll manage fine, but the trick will be for him to carry the lessons over into his other projects. When I tried the other day to give him pointers, he didn't see why it was needed, and thought his code was fine the way it was. Part of the trick in games coding is writing something, and rewriting it over and over until its small enough, and fast enough, but these days with all the CPU power available to the average user, its easy to lose sight of that. Windows is a good example, in the days of Windows 3.1, it was actually around the same speed as what we have today, in fact in many ways it was way quicker. Whats changed? People have become used to all the power, and have wasted. Windows is full of really bad code, the fact that it can take a whole minute to enter a directory, or bring up the add/remove programs dialog shows this.

    Wednesday, May 03, 2006

    Beginners Luck

    I've been thinking of that BASIC for a console again, and the more I think on it, the more I think its a good idea. I think I'd probably have to drop the idea about doing inline assembly, but the rest of it sounds good fun. I love the idea of giving Kids a simple toy to play with and learn at the same time. I also like the idea of writing a simple version of BASIC; never done one before so it could be fun!

    I was looking though some code and have come back to the conclusion that I don't like the way C++ programers are heading. Theres too much use of the lanugage just for the sake of it. My view is that if I can do something simpler, smaller and faster than a fancy C++ templated STL'ed version then thats what I'll do. But the more I look at others code, the more I think they use all these features and extensions just for the sake of it. Russells usually fairly good with these things, so I hope that his usage won't pee me off when he finally gets around to writing it. If it does...that could be my signal to leave now. Its funny, Dave says he lets his team leaders manage the teams however they want as long as they produce the goods. In a way I think thats good, but in another... I don't like it. I can't put my finger on exactly why either...I'm sure its something to do with having at least a "basic" standard thought a company though, where as it looks like we're heading for at least 3 just now.

    I've asked Russell to go over some code with Andrew to try and give him some pointers. He's doing fairly well but still has a bit too much "University boy" in him for my liking. All juniors start out like this, but it's a bit irritating that universities still can't teach "nice" code, although I probably shouldn't be too surprised since these places are usually around 5-10 years behind an industry. I'm not sure where he went to school, I know Abertay is fairly good with its games course, but Dundee University is fairly pants at its programming courses. I remember interviewing a guy from there that didn't know how many bits were in a normal "int", or how sign (+/-) was done. Thats just scary. But whats probably worse, is that these people actually pass!!

    Tuesday, May 02, 2006

    Basic programming.

    I've been thinking more about writing a simple BASIC with some of the features I listed yesterday, and the more I think about it, the more I think Sony were on to something - if only they'd done it right. YaBasic on the PS2 was a great idea, but the BASIC was buggy and you simply couldn't do very much with it. Not only that, but there was no way to get programs out there to others short of handing over a memory card with a program on it. No, whats needed is an XBox arcade style thing where you can upload your programs and give them out in an easy to reach place.

    Heres what I'm thinking... Write a nice version of BASIC, add some simple sound and sprite control, along with something for them to peek and poke, and perhaps even do a little bit of ASM when the mood takes them. The package starts up in a fullscreen editor just like the spectrum and C64 used to, which means all a kid needs to do is boot it up and go. Then, get it on a cover disk so that everyone can get it - or somehow sell it cheap or something. And then let kids have fun. A cross between spectrum and BBC basic would be great. Simple graphics controls, UDG graphics and sprites (which appear like the hardware ones on the C64) and perhaps even some sort of scrolling system. This should let anyone write a nice simple 2D game.

    I dont think 3D should really be used. Things get complicated once you add that, and if you make it available, people want to jump right in and write Quake - thats not the idea. We need nice simple 2D games that let people learn, and then give them more direct access to the machine so that you can expand your understanding.

    Now...while MS might let you sell a version of BASIC, Im not so sure about allowing assembler since that "could" then compomise the whole system. Once you can run user code... you can find holes and open the flood gate. Im sure it wouldn't be long before someone got a way to load hacked games from it. Perhaps running a simulated language 6502, Z80 etc. would work fine. Of course... it would probably be no quicker than the BASIC thats being run, so why bother... I need to think on it a little more.

    Monday, May 01, 2006

    Future games programmers.

    I've been reading some other blogs on here, and a couple jump out. One of them go went on about how hard it is for young people to start programming. In the past (in the days of spectrums and C64's) you would switch on a machine and bang, you'd be ready to code. Now its very very tricky. Getting even the most basic program is way beyond what a 10 year old is able to do. But in the past you could give a child a TV, a computer and a very simple manual.

    So what did these old machines - lets take a Sinclair Spectrum as the example - have to offer. First, as soon as you start your in the BASIC editor, this means theres nothing complex for a child to do in getting up and running. Second, you have direct access to the screen and simple graphics. Third having complete access to the machine and being able to PEEK and POKE everywhere allows very simple hacking and lets teenagers and the like get to know what a machines like and what makes it tick. Machines like the C64 add things like hardware sprites, character map screens, sound and music and rasters.

    So, what does the modern machine offer? Well, they're big and powerful and have complex 3D built in not to mention great FPU support. But what do you have to do to actually use a PC to program? Well some sort of BASIC would be nice, but Visual Basic isn't "simple" by any means for a child to use. This means you would have to get some sort of QBasic, FreeBasic orYaBasic etc. Once you have all this, making graphics and sound etc. is still a fairly complex process.

    All this adds up to a growing problem, computer programming is getting harder and harder and as such, professions like mine will become harder and harder to break into.

    The other blog was on one that went into detail about just how hard it is to break into the industry in the first place. This blog explains that in rality there isn't actually a lot og games programmer jobs going around, and that with a lot of new talent comming in, theres less and less available.

    Now, put these together, this adds up to less people interested in coding, and even less people having the interest in games programming. Normal programming is fairly simple, and even if you're bad at it, you can still make a living doing things like database coding, internal applications software and the like. But you dont last long as a games coder, if your hopeless; you might get by for a few years... but with the way games technology is heading... it'll outgrow you quickly.

    Oh well....perhaps someone will bring out a "retro" machine that "Kids" can code again.