by date
Plan for Byron Atkinson-Jones
Plan for Byron Atkinson-Jones
| Name: | Byron Atkinson-Jones | |
|---|---|---|
| Date Posted: | Sep 24, 2005 | |
| Rating: |  Not Rated | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Byron Atkinson-Jones |
Blog post
Coming from a background where I started my coding career on a spectrum and C64 Torque 2D is going to allow me to realise my old dreams of games that I never got around to coding. But, good as it is Torque 2D is not quite where I need it to be so I am going to attempt to extend it...
I only came across Torque 2D very recently and after a little mulling around I finally took the plunge and bought a licence to it. I was quite lucky in that I had bought a licence to TGE when it first came out so I could opt for the $80 version.
Why did I take my time in making a decision?
Snobbery really....
I work in games and its difficult to get out of the mind set of needing to create a game that will appeal to the masses and hence need to be 3D. I wanted T2D because I started out on the C64 and there were a few games that are 2D in nature that I wanted to create - just for me... if anybody else likes them then that will be a bonus!
Anyway - I have it now... so what next?
Well, one of my first tasks is to integrate my Flash player into the core C++ code. For some bizarre reason my career in the games industry has led me to the position that I always end up involved in the GUI code for the game and every game I worked on re-invented the wheel and created a new GUI system and a new GUI editor. This seemed like madness to me so I began to experiment with using Flash as a GUI editing system for games. Eventually Serenity Interface was born. This is a cross platform 'flash player' (in quotes because it is not a flash player in the same sense as the Macromedia Flash player - Serenity Interface is designed for low memory cost and high performance games.. especially console development and does not use the native SWF format, rather it converts from SWF to its own format) which means I can now design all my game GUI's in Flash - which for me is cool!
I have no idea how difficult a process the integration into the T2D core will be but it should be fun!
I am guessing this is going to take me through most of the major sub-systems in T2D and I especially looking forward the scripting integration.
The result? I can at last realise those old dreams!
Why did I take my time in making a decision?
Snobbery really....
I work in games and its difficult to get out of the mind set of needing to create a game that will appeal to the masses and hence need to be 3D. I wanted T2D because I started out on the C64 and there were a few games that are 2D in nature that I wanted to create - just for me... if anybody else likes them then that will be a bonus!
Anyway - I have it now... so what next?
Well, one of my first tasks is to integrate my Flash player into the core C++ code. For some bizarre reason my career in the games industry has led me to the position that I always end up involved in the GUI code for the game and every game I worked on re-invented the wheel and created a new GUI system and a new GUI editor. This seemed like madness to me so I began to experiment with using Flash as a GUI editing system for games. Eventually Serenity Interface was born. This is a cross platform 'flash player' (in quotes because it is not a flash player in the same sense as the Macromedia Flash player - Serenity Interface is designed for low memory cost and high performance games.. especially console development and does not use the native SWF format, rather it converts from SWF to its own format) which means I can now design all my game GUI's in Flash - which for me is cool!
I have no idea how difficult a process the integration into the T2D core will be but it should be fun!
I am guessing this is going to take me through most of the major sub-systems in T2D and I especially looking forward the scripting integration.
The result? I can at last realise those old dreams!
Submit your own resources!| Byron Atkinson-Jones (Sep 24, 2005 at 11:04 GMT) |
| Tom Bampton (Sep 24, 2005 at 12:09 GMT) |
| Ben Garney (Sep 24, 2005 at 17:57 GMT) |
| Byron Atkinson-Jones (Sep 24, 2005 at 19:45 GMT) |
Serenity is designed specifically for hw accelerated platforms - such as PS2, XBox, Gamecube and most modern graphic cards which a software render system would kill in terms of performance.
Besides, the integration will be the best way for me to get to know the source code base of T2D. :)
| Byron Atkinson-Jones (Sep 24, 2005 at 21:19 GMT) |
GameSWF is a fantstic piece of software and a real alternative to the official Macromedia Flash player - especially if you have a situation where you just can't use the official player. However, since my goal of creating Serenity was for use in commercial games I knew that the game developers I worked with would not accept a software-rendered solution. There are also problems in that since GameSWF reads native SWF files there is an overhead cost of keeping two copies of resources in memory - the compressed form in the SWF file and the un-compressed form. SWF is great for web use because the file format has a compression scheme in the form of a bit stream - one console in particular is VERY picky about memory access on aligned boundaries and will actually generate an error if it can't which means interpreting the bit stream becomes very problematic and slow. So the solution is to convert the bitstream into something that the console can deal with. This is what Serenity does - but it does it as an off-line process so that you do not incurr huge load times at run time.
There is also the problem of software rendering. Software rendering can take a number of approaches. One is to render byte by byte into a texture and then upload this texture into video memory or use the hw rendering primitives to implement the software rendering for you, and another approach is to directly access the frame buffer. Each of these options is extremely slow and will end up either chocking the data bus with uploading large textures or at the very least (in the case of accessing the framebuffer) end up eliminating any potential asynchronous operations the driver can convert your rendering into (drivers can typically implement triple buffering without your request - but asking to access a texture to read it back to main memory will cause the driver to flush all drawing commands - causing huge stalls).
Those are some of the reasons why I chose not to use GameSWF but each reason does not deter from the fact that GameSWF is an excellent piece of software for the market it is aimed at and long live it!
You must be a member and be logged in to either append comments or rate this resource.
