GP2X Tiny Pong
- Thread starter gfoot
- Start date
iignotus
The one and only
Hey I don't go around mocking your God.Alex. posted on Aug 28 2006 at 09:12 PM said:
Last edited by a moderator:
torpor
hack hack hack, the little machines fight back
Just so its clear: 512byte Pong is cool .. because of the tools it now gives us.
And: 512byte VoxelRenderEngine will be cool too!
(And I'll wear my PONG t-shirt to work tomorrow to make amends for coming off sounding like a jerk..)
And: 512byte VoxelRenderEngine will be cool too!
(And I'll wear my PONG t-shirt to work tomorrow to make amends for coming off sounding like a jerk..)
yaustar
UK GP32 & GP2X Owner
Need pictures for proof 
I gutted it last night and turned it into tinylife instead - still 512 bytes, plenty of which is wasted on input processing, which I dropped in right at the end.
http://www.glost.eclipse.co.uk/gfoot/gp2x/tinylife.zip
B = reset, X = pause, A = slow, Start = quit (in true GPH/Microsoft style)
It doesn't exec the menu on exit, but hey, it's not a .gpe so it doesn't appear on the menu anyway. Wrap it in a script if you like.
I was expecting it to run quite slowly, but I'm now vaguely impressed with the memory access bandwidth etc, using cached memory at least.
There's nothing particularly groundbreaking here - the LCRNG code might be interesting though, as you can do it in a single instruction on ARM. The values of A and B came from wikipedia. Luckily the values are such that the whole parameter block can be overlaid on the elf and program headers, so the storage cost is pretty much zero.
The random number processing is perhaps a bit over the top - even with good A and B values, LCRNGs tend to give poor randomness in the lower bits, and with this kind of filling-the-screen-with-random-pixels code you start seeing visible patterns if you use the bottom 10 bits or so.
I initially jumped through a few hoops to get reasonably good results - picking four high bits and spreading them out to bits 0, 8, 16 and 24 of a word to write - which gives a nice random snowstorm when you hold down B. I tried just using bits 0,8,16,24 directly, and the results were terrible; you can also embed a shift in the same instruction, so I tried shifting it 6 or 7 bits to the right, getting some improvement. In the end I added an eor between high and low bits to shake things up a bit, which costs another instruction but gives a good quality snowstorm.
http://www.glost.eclipse.co.uk/gfoot/gp2x/tinylife.zip
B = reset, X = pause, A = slow, Start = quit (in true GPH/Microsoft style)
It doesn't exec the menu on exit, but hey, it's not a .gpe so it doesn't appear on the menu anyway. Wrap it in a script if you like.
I was expecting it to run quite slowly, but I'm now vaguely impressed with the memory access bandwidth etc, using cached memory at least.
There's nothing particularly groundbreaking here - the LCRNG code might be interesting though, as you can do it in a single instruction on ARM. The values of A and B came from wikipedia. Luckily the values are such that the whole parameter block can be overlaid on the elf and program headers, so the storage cost is pretty much zero.
The random number processing is perhaps a bit over the top - even with good A and B values, LCRNGs tend to give poor randomness in the lower bits, and with this kind of filling-the-screen-with-random-pixels code you start seeing visible patterns if you use the bottom 10 bits or so.
I initially jumped through a few hoops to get reasonably good results - picking four high bits and spreading them out to bits 0, 8, 16 and 24 of a word to write - which gives a nice random snowstorm when you hold down B. I tried just using bits 0,8,16,24 directly, and the results were terrible; you can also embed a shift in the same instruction, so I tried shifting it 6 or 7 bits to the right, getting some improvement. In the end I added an eor between high and low bits to shake things up a bit, which costs another instruction but gives a good quality snowstorm.
Wow amazing stuff. ARM code is so efficient.
The good thing about this is it shows you could write something pretty useful for the second 940 processor and keep it within the magic 4096 byte icache barrier.
Just a suggestion but any chance of trying a parallax star field program. In theory if you could get it to run on the 940 and use the YUV layer. You could then use the RGB layer transparency thingy to show the star field in the background without using any of the main processors processing power.
The good thing about this is it shows you could write something pretty useful for the second 940 processor and keep it within the magic 4096 byte icache barrier.
Just a suggestion but any chance of trying a parallax star field program. In theory if you could get it to run on the 940 and use the YUV layer. You could then use the RGB layer transparency thingy to show the star field in the background without using any of the main processors processing power.
Squidge
Certified Guru
It would still use up a significant amount of the A/D bus though, therefore slowing down the main processor.
Squidge posted on Sep 2 2006 at 11:58 AM said:
Yes you are right. My fault for misreading the MP2520F_Manual_Eng_V1.0 docs wrong. I saw the bit about 4 parallel data bus accesses but didn't realise that's 1 for each internal data bus i.e. memory, i/o, fast i/o and internal. So you can only have one device access memory at any one time.
It looks like the only efficient way to use the 940 is to have both the code and it's data fit inside their respective i and d-caches.
I wonder how much band width the LCD controller eats up. Has anyone tried switching it off and doing benchmarks? I remember the SAM coupe (don't ask) had a 6MHz Z80 processor but with the memory contention from the video controller it ran at the equivalent of a 4MHz processor.
Last edited by a moderator:
Alex. posted on Aug 28 2006 at 08:56 PM said:Dzz, remember that for every twat there are ten people who actually appreciate developers' work.
- Alex
LOL, funny but true. I understand the frustration wanting a 3D engine on the GP2X, but that's no reason for torpor to reply that way. I guess it wasn't intended to be so sharp.
It's going to be a huge task for someone to write a decent 3D engine using ASM, and that's exactly the reason why don't have one yet.
Nice work gfoot, very impressive stuff. It's thanks to people like you and Dzz that I keep coming back to the GP2X and trying to improve my skills.
Last edited by a moderator:
Or do very CPU-intensive things on both 920 and 940, even if the data doesn't totally fit in cache. While it's better if it does fit in cache, if the memory access to instruction ratio is low enough the 920 and 940 might not trip each other up too much. Floating point maths springs to mind, having a lot of in-register processing compared to memory loads and stores. The 920 and 940 might work well together in a 3D engine, too, with one transforming the vertices (lots of maths) and one rasterizing and writing output pixels (lots of data). The framebuffer output might start to choke the vertex transformer though.
To some extent the memory bandwidth would constrain the overall performance, which means you've potentially got a lot of CPU power left over. If you can find something useful to do with those cycles, they're basically free - e.g. maybe it is practical to use floating point maths, and do proper perspective divides, if the cycles are just being wasted anyway.
To some extent the memory bandwidth would constrain the overall performance, which means you've potentially got a lot of CPU power left over. If you can find something useful to do with those cycles, they're basically free - e.g. maybe it is practical to use floating point maths, and do proper perspective divides, if the cycles are just being wasted anyway.
xafier
Member
a Voxel engine isn't exactly 3D... well, not if its one based on a heightmap and a texture bitmap or pure shaded on height.... I'm currently looking at having a go at writing a voxel engine... but it'll be a fair way off 512 bytes at first thats for sure
i'm hoping once its done in its first version i'll be able to work on learning arm assembly and improving it and then hopefully pushing it onto the 940 and use the 920 to do other logic and work on a game possibly for entry into one of the competitions
i'm hoping once its done in its first version i'll be able to work on learning arm assembly and improving it and then hopefully pushing it onto the 940 and use the 920 to do other logic and work on a game
possibly for entry into one of the competitions
