Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Canopy

Pages: [1]
Sundown 2013
6-8th September
Budleigh Salterton, UK

Kickstarter type thing for a FOUR disk (3DVD + one Blu-Ray) version of the Moleman2 doc.

Works out at just under 14 quid UK plus the 8 euro shipping which i guess is another 4/5 ?

Since there's the brill demoscene seminar video post i thought i'd drop any thing decent OpenGL / OpenGL ES related I find in here.

There are some good intro videos by several universities on youtube which i'll dig out soon.
(will purposefully avoid tutorials obviously written as a method of self-documentation..)

Post on the Raspberry Pi forum where someones collected samples that will build on the Pi and Windows
(they have a dedicated opengl es  section and a graphics prog section too)

i'm guessing a lot of people (like myself) who grew up with amigas and such like know via cracktros and trainers, and 'demo disks'  there's the odd small gui serial/cracktro for software but other than that.. 

how do 'kids' these days find out?

Hi Everyone,

Here's my challenge entry  - Written using Visual C++, for OpenGL ES 2.0, the only external tool used was Pixel Font ( ) 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 ->

- Canopy

General chat / castle story anyone?
« on: July 28, 2012 »
i'm not really a gamer, but a coworker told me about this yesterday a few hours before their kickstarter went live and i was hooked.

they had a goal of 80k, had broken that within 5 hours, and now have 180k as i post this less than 24hrs later

hi guys,

i'm planning the my opengl project base code, and the first phase is primarily 2D based.

what i plan to do is have a 'decoupled' base code (call it an engine if you like) that has 2 parts.

1) this part deals with calculating/updating the effects
2) this part deals with sending the effect to the gl library, and handles any updates

to begin with lets say the effect is a huge 2d plane/chessboard, i want the screen to be able to go from being at pixel level to zooming in and rotating.

after that i'll  want to dynamically be able to change the colour of each square (say to bounce a different coloured square around the grid) or do some colour cycling effects - all kinds of stuff. basically this matrix is the playground of a certain class of my effects.

from what i've read i should deal with triangles.. so for each chessboard square draw the two triangles

i understand the whole keeping lists in faster gpu memory thing and with a bit of work i can work out which 'squares' have changed so i can adjust list that has already been sent to the card.

but this is where i'm confused.

i also read i should be using vertex arrays and not vertex buffer objects as they're deprecated. then i'll find something that says the opposite - this is confusing me as everytime i look up vbo's they're positively suggested over vao's.

i think part of this is due to them not being deprecated in opengl es? (which in turn i think is because in SoC type devices the ram for cpu/gpu is partitioned, so there's not much point differentiating)

so to be bang up to date and not using stuff thats deprecated. what should i use?

as an additional gotcha.. i'd hope to maintain compatibility with opengl es 2.0.

although i'm going to be working under opengl on windows, i hope to down the line recompile without too much effort on arm based devices like the raspberry pi and tablets using that kind of SoC with open gl es 2.0 on board.

Pages: [1]