A lot has happened since I last posted here. I've dropped Mattise and rejoined the Pedigree project (http://code.google.com/p/pedigree).
The Pedigree project has allowed me to do some pretty crazy things - writing all sorts of code including a fully functional TCP/IP implementation.
And that's what's brought me back here.
I've got a few 3Com 3C90x NICs lying around the place here, and I thought it'd be nice to write a driver for them so I could test out Pedigree on some of the boxes I have around the house. However, I struck a problem very quickly - no emulator for x86 has a 3Com card emulated!
A quick Google search showed me that PearPC had an emulation of one, but because it's a PPC emulator it wasn't useful to me (our PPC port is still a bit behind, unfortunately). PearPC's emulation is licensed under the GPLv2, as is QEMU's (our emulator of choice). So I thought it'd be fun to port it across.
The first hurdle was that PearPC was in C++ and QEMU in C, and their entire interface to the virtual state was different. After an hour or two I'd fixed that up. However, I ran into a slight problem - the emulation was incomplete. So for the past day and a half I've been reading the specification for the card and updating my emulation code, while also updating my own driver.
So I've been working on a driver for (and an emulation of) this NIC, which has been a huge challenge and all up, a lot of fun!
It's an amazing feeling when you successfully create and close your first TCP connection. You can imagine how much more incredible it is when you watch "lynx" (the text-based browser) running through your NIC driver, controlling your emulated NIC, do a full request and print the page.
I will be submitting the 3C90x emulation as soon as it's more complete, cleaned up a bit, and most importantly - tested!
Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts
Friday, May 01, 2009
Saturday, September 29, 2007
On Game Development
Due to my recent lack of success in game development (a 3D FPS is quite a challenge at times - more on this later), I've decided to go back to the first game I wrote - a simple "Pong" clone with a couple more features and a nasty AI.
My 3D FPS works nicely, it loads levels and you can move around in them, but I never got collision detection setup in the engine, or any guns or any FPS-related stuff. I was mainly concentrating on getting a scripting engine setup for it, and after I got boost::python to work in the engine I realized most parts of the engine needed to be rewritten anyway because they were slow and causing massive code bloat.
My old Pong game works nicely as well. You can load it up, select the difficulty level from the (extremely) rudimentary menu, and the AI can get tough. Unfortunately it was plagued by my lack of knowledge of the DirectX APIs and hence code is scattered everywhere in an attempt to make a working game.
The new one will use a simple structure to do its work - not one massive procedure called every time the screen needs to be rendered. With a separate procedure for AI, physics, and drawing, the internal code base becomes much simpler and easier to work with. Monolithic functions (ie, those with > 100 lines of code) will be split into multiple (smaller) procedures.
And, possibly one of the most important things, the menu will be separated from the main game loop.
I don't know what I was thinking when I wrote the first revision of Pong, but for some weird reason I decided it'd be a good idea to put the menu code into a conditional block:
The initialization for the menu was a bunch of hacks to get a bunch of strings into an array - now I know better methods for doing this. Often the menu strings would mingle with each other and end up becoming quite confusing.
The new game will hopefully fix all these bugs in the initial code base and utilize the full power of DirectX 8 (instead of DirectX 1 which I was using before). The final planned feature is something that all my friends suggested after playing the first version - "Add networking". It should be fun to write a basic protocol that updates paddle and ball position for a single client. Or even to have a fancy "spectator" view and a "tournament" mode for those who wish to have a LAN party with a bunch of mates.
It shouldn't take too long (hopefully no more than a month) and I'll post a link to the final binary when I'm done.
My 3D FPS works nicely, it loads levels and you can move around in them, but I never got collision detection setup in the engine, or any guns or any FPS-related stuff. I was mainly concentrating on getting a scripting engine setup for it, and after I got boost::python to work in the engine I realized most parts of the engine needed to be rewritten anyway because they were slow and causing massive code bloat.
My old Pong game works nicely as well. You can load it up, select the difficulty level from the (extremely) rudimentary menu, and the AI can get tough. Unfortunately it was plagued by my lack of knowledge of the DirectX APIs and hence code is scattered everywhere in an attempt to make a working game.
The new one will use a simple structure to do its work - not one massive procedure called every time the screen needs to be rendered. With a separate procedure for AI, physics, and drawing, the internal code base becomes much simpler and easier to work with. Monolithic functions (ie, those with > 100 lines of code) will be split into multiple (smaller) procedures.
And, possibly one of the most important things, the menu will be separated from the main game loop.
I don't know what I was thinking when I wrote the first revision of Pong, but for some weird reason I decided it'd be a good idea to put the menu code into a conditional block:
if( inMenu )
{
// do menu stuff
}
else
{
// do game stuff
}
The initialization for the menu was a bunch of hacks to get a bunch of strings into an array - now I know better methods for doing this. Often the menu strings would mingle with each other and end up becoming quite confusing.
The new game will hopefully fix all these bugs in the initial code base and utilize the full power of DirectX 8 (instead of DirectX 1 which I was using before). The final planned feature is something that all my friends suggested after playing the first version - "Add networking". It should be fun to write a basic protocol that updates paddle and ball position for a single client. Or even to have a fancy "spectator" view and a "tournament" mode for those who wish to have a LAN party with a bunch of mates.
It shouldn't take too long (hopefully no more than a month) and I'll post a link to the final binary when I'm done.
Subscribe to:
Posts (Atom)