Dark Bit Factory & Gravity
GENERAL => Challenges & Competitions => Topic started by: Canopy on February 20, 2013
-
Hi Everyone,
Here's my challenge entry - Written using Visual C++, for OpenGL ES 2.0, the only external tool used was Pixel Font ( http://www.min.at/prinz/software/pixelfont/ ) which exports a header file used to generate 8x8 arrays used to draw characters (that look like the windows system font)
Due to differences between the AMD and the Mali implementations of EGL config set up stuff I've had to provide two exe's, they're in obviously named sub folders.
If you're using a recentish ATI/AMD card the native implementation should just work (tm)!
Otherwise Mali will, but its slower because its emulated over normal GL.
(One of them should work with ANGLE DLLs from other implementations)
Out of scope there are some keypresses too
SPACE - pauses
PLUS - increases the number of UDGs on screen (makes it slower)
MINUS - - decreases the number of UDGs on screen (makes it faster, i think zooming once makes the copperesque bit run at super speed)
Will post some more info on the implementation tomorrow as I've written that on my laptop. But to give an indication the last screenshot attached I ran it with wireframe mode on and zoomed in to show the UDG triangle construction
Vimeo Link -> https://vimeo.com/60122930
- Canopy
-
is there somethings wrong because I run the program and I get big window screen white(I thought I could resize the window)
I will show you what I mean
(http://www5.picturepush.com/photo/a/12236938/220/12236938.png) (http://picturepush.com/public/12236938)
It`s Shouldnt happen like that? Right?
It is interesting on what you have done thought :)
-
resize isn't a good idea :( sorry! ...and thanks! :)
-
Couldnt you resize the window and what programming language were written in?
-
pretty much straight C as a win32 api application (no MFC)
i can only resize by double clicking the title bar or docking it on win7 which screws it up.
-
i can only resize by double clicking the title bar or docking it on win7 which screws it up.
Bummer but good things that you Release on DBF UDG Challenge Entry
Well Done :clap:
-
Mali worked for me, but it was indeed quite slow on my laptop.
Well done on your first ever demo though, cool to have you enter the comp! :cheers:
-
You've got potential - there's plenty going on in this program for a first demo.
-
Thanks!
Just arrived at work, so can paste the details on the implementation i'd prewritten on my laptop now.
The UDGs are rendered using what i've internally called 2D Grid in my code.
In the 2D Grid the screen is divided into blocks, the number of which is divisible by 8.
So on the x-axis to have 256 blocks takes 4 pixels (1024/256==4), to have 128 takes 8 pixels (1024/128==8).
Every time an individual block is drawn a single pair of triangles (in a VBO) is reused. As i've used OpenGL ES, a lot of the work is done in the shaders, including the translation (position), aspect ratio correction and colouring.
The 2D Grid can be refactored at run-time to modify the block size (which configures the size of the stored triangles in the VBO) but still conform to a screen width in blocks that is divisible by 8.
So the 2D Grid code is used to render each UDG an array of 8x8 'blocks'.
In the case of a single 8x8 text character on the screen is drawn using UDGs, which in turn are drawn using 8x8 2D Grid blocks. Each of those 2D Grid blocks is 2 triangles in a VBO 'instanced' over and over again via the shader. So one text character on screen is 64*64=4096 blocks or 64*64*2=8192 triangles.
Lessons learned
As stated before this is my first demo and challenge entry, prior to this challenge I'd only ever fiddled with a recompiled 3D Cube sample from the Mali SDK and written the 'hello triangle' sample. Pretty much everything has been learned and done from scratch.
What I brought in from the fiddling i'd done with the previous stuff was some high resolution delta timing code, and some windowing set up stuff i'd done while building upon those two things.
I'm really happy in how i've seperated things. I've got a platform.lib which calls an app specific entry point for 'setup' and contains the things dependent upon O/S, like timing, input and handling windowing. The other library is stuff thats reusable code common to everything (I'm not calling this an engine.. as per this brilliant article someone linked on DBF previously http://scientificninja.com/blog/write-games-not-engines )
I've chosen OpenGL ES as I do hope to be able to port code across to devices like the Raspberry Pi and have ideas for some interactive stuff on tablets.
However after hitting performance issues with the onboard intel card my motherboard had, and discovering most OpenGL profiling tools require firstly, better cards and secondly full GL. I've decided the future lies in making a 'normal' GL version of my platform lib for desktop development to take advantage of profiling tools in future, and so that in future challenges more people might be able to actually run them! (I will try to stick to the methods available in both desktop OpenGL and OpenGL ES 2.0 to do this though).
As far as other performance goes, I could have probably gained some by using a VBO list per UDG and reusing that.
Going forwards, i've learned a lot, and the pixel font rendering code particularly will help if i want to write a console interface or simply show an FPS counter.
-
Looks nice, Canopy. Although it runs really slow. Even using -/+ does not really speed this up.
Will check this on another computer at home.
-
Pretty nice, Canopy for a first demo especially!
-
thanks :)
I've been reviewing my notebook and have made a list of adjustments to make to my libraries/code, and have realised that as well as this challenge teaching me a lot I have some good stuff to build upon.
hopefully another challenge that takes my fancy doesn't pop up before i've got that groundwork done!
there's a scope for massive optimisation by 1) using a VBO per UDG rather than for each square and then following from that - i think i reinvented in my head what is similar to the "stripe" algorithm i just found in the Real-Time Rendering book. all this code in my ever evolving libraries will help as its leading me towards one of my goals :)
-
Hi Canopy, well done on your first ever demo :)
-
Really nice for your first attempt in creating a demo. Looking forward to see more from you in upcoming challenges! :)
-
Well done Canopy :) This reminds me of a very early cracktro. I like the way the text moves in at the beginning, it's a very nice opening touch. K++
-
Well done for a first try!
-
Thanks again for the kind words guys :) k++
Hopefully next one will be even better.
I'm still coding off the back of this and pretty much up to speed now with Desktop GL plus some improvements like alt-enter windows/fs support etc..