Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    455
  • comments
    639
  • views
    424262

Some considerations...

Sign in to follow this  
_the_phantom_

123 views

Fun Factor!
My GP2x got its first road test today, I went out tonight to a local alternative night and figured I'd take it with me as (a) a mate wanted to see it and (b) its always handy to have something to play on [grin]

Firstly, while I knew it was small and light, damn the thing fits well into my pocket, I hardly notice it there!

And it was an instant hit, heh, I put a couple of emulators on there and my mates gf spent ages playing Sonic on it, much to the batteries distress [grin]

Which got me thinking, why is it, that around 10 years later, games like Mario and Sonic are still loads of fun? I know that often when people talk about how good old games were they are often dismissed because the passage of time tend to make things in the past look better, but its hard to dispute it for certain games, such as Sonic, which even now are as cool to play as they were back when I was 14 or so.

The plan!

So, I figure, as I've layed out the cash I should start doing something productive with the GP2x besides playing cool games on it, so I've decided, as a learning exercise, to write a title based game, using the 2nd CPU as a pure drawing machine.

My inital thoughts into it have mostly consisted of doing the following;
- loading up titles and giving them a numbered id
- title texture data is moved into memory the 2nd core can access
- then the first core sends the 2nd core drawing instructions in the form of a run lenght encoded (RLE) data stream which instructs it to pull a certain texture from the memory pool and draw it.
- The 2nd core then reads the data from the FIFO buffer, decoding and drawing as required.

the scheme is pretty simple, much like a RLE bitmap, you have a header byte, count byte and then data bytes.
Infact, the header and count bytes could be combined into one byte, with the MSB being set high or low depending on the data to follow.
Normal blocks would be in the form;
(upto "count" block ids>
RLE'd data would be


This suits its self perfectly to games of a simular style to Mario which do have alot of repeating blocks.

Once thats done I'll work on a command stream for drawing none-block aligned sprites.

Shaders?

Another thought I had on the way down here was how todo some sort of 'shader' system, so that certain code could be executed while the 2nd CPU is drawing the data.

The very basic idea I came up with would be along the lines of the title system above;
- you create an id
- you then associate some code with that id

The code might need to be copied into the 2nd CPU's memory space, I havent worked that out yet, but I guess that would be the case (unless some really clever stack hackage could take place to get the functions general address, we'll have to see).
Then, when drawing you set a certain id to be used and all data is first routed via that function before being sent to the framebuffer.

If I develop this idea then it'll come after the inital game/engine is done and I've learnt more about programming the thing, however I think its an idea which might have legs [smile]

Thats all for now, I need to get a pizza to soak up some of the vodka I had tonight, vodka + reef mixer is a pretty deadly combo it seems.. [wow]
Sign in to follow this  


2 Comments


Recommended Comments

The low-level coding of that unit still baffles me. Have you checked out ryleh's minimal library? It lets you execute programs on the second cpu.

Share this comment


Link to comment
aye, that lib has been my main source of low level information right now, I need to cross check a few things with the docs on the ARM chips and the MagicEye chip as a whole, but I think I understand whats going on [grin]

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!