1
Challenges & Competitions / Re: [LIQUID] - color paint
« on: March 09, 2010 »
That is excellent - loved it!
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.
Pages: [1] 2
That is excellent - loved it!
2
Challenges & Competitions / Re: [Time Challenge] 1Koder Colour Clock
« on: March 23, 2009 »
I've just added a couple of links to the top of this Thread for KKapture movies of it running for those having problems displaying it - the long one is a complete cycle but is 100MB, the shorter one <26MB and is adequate to get the idea of what it does 
3
Challenges & Competitions / Re: [Time Challenge] 1Koder Colour Clock
« on: March 17, 2009 »
That's odd 
Can't think it does much after 10 seconds that it doesn't do from the onset, although the uptime is a feed into the pattern so I guess it could be after any duration that the cause really happens...it's runtime checks are minimal to fit it in 1k, so maybe something else running on there throws this off course (although I have virus checkers and Spybot etc on my machines here, and it stays running on both my ATI/NVidia cards for longer than I can stomach to watch) ...
...out of interest, what OS & Gfx card are you using there?
Can't think it does much after 10 seconds that it doesn't do from the onset, although the uptime is a feed into the pattern so I guess it could be after any duration that the cause really happens...it's runtime checks are minimal to fit it in 1k, so maybe something else running on there throws this off course (although I have virus checkers and Spybot etc on my machines here, and it stays running on both my ATI/NVidia cards for longer than I can stomach to watch
) ... ...out of interest, what OS & Gfx card are you using there?
4
Challenges & Competitions / Re: [Time Challenge] 1Koder Colour Clock
« on: March 16, 2009 »
I meant to mention that - I've replaced the download at the top of the Thread with the new (and hopefully working one), cheers!
5
Challenges & Competitions / Re: [Time Challenge] 1Koder Colour Clock
« on: March 16, 2009 »
Thanks Hellfire for that tool, I'd not seen that before 
...I'd tried it on an ATI card here which worked, but I guess I just got lucky with that - I've now added a "." after the 63 and the tool validates it fine...and fortunately it didn't change the compressed byte-size.
Thanks again
...I'd tried it on an ATI card here which worked, but I guess I just got lucky with that - I've now added a "." after the 63 and the tool validates it fine...and fortunately it didn't change the compressed byte-size.
Thanks again
6
Challenges & Competitions / [Time Challenge] 1Koder Colour Clock
« on: March 14, 2009 »
Hi,
To my shame I haven't posted at DBF in ages, so I was determined to enter a competition with something...even though nothing can better Digital Watch Brawl IMO!
Anyway, this proggy displays the system uptime in 1k with moving background colours (as that's what I like
) ... if you're lucky enough to have a system that's been up for >99 days, I probably wouldn't try it...
...basically it was for me to try using a GLSL shader with text in 1k...it means the shader is a bit simple, but my desired one just could not lose the last 64bytes that I needed to
...to fit this in 1k there's some pretty bad practices going on in there - but the source is included in case of use/interest to anyone. Obviously it's derived from information found on the DBF site, and IQ's site too http://iquilezles.org/www. It's packed with Crinkler 1.1a http://www.crinkler.net, unpacked version is included too.
It requires shaders (2 I guess), runs with 1024x768x32 display...and I've tried it on [XP64 NVidia 9600 GLI] and [XP ATI HD2600 PRO] and [Vista NVidia 7650 GS] without problems, so fingers crossed it'll behave for you.
[Edit] Corrected vertex shader code (some ATI cards)
[Edit] Re-uploaded the zip/piccy after DBF server crash
To my shame I haven't posted at DBF in ages, so I was determined to enter a competition with something...even though nothing can better Digital Watch Brawl IMO!
Anyway, this proggy displays the system uptime in 1k with moving background colours (as that's what I like
) ... if you're lucky enough to have a system that's been up for >99 days, I probably wouldn't try it......basically it was for me to try using a GLSL shader with text in 1k...it means the shader is a bit simple, but my desired one just could not lose the last 64bytes that I needed to
...to fit this in 1k there's some pretty bad practices going on in there - but the source is included in case of use/interest to anyone. Obviously it's derived from information found on the DBF site, and IQ's site too http://iquilezles.org/www. It's packed with Crinkler 1.1a http://www.crinkler.net, unpacked version is included too.
It requires shaders (2 I guess), runs with 1024x768x32 display...and I've tried it on [XP64 NVidia 9600 GLI] and [XP ATI HD2600 PRO] and [Vista NVidia 7650 GS] without problems, so fingers crossed it'll behave for you.
[Edit] Corrected vertex shader code (some ATI cards)
[Edit] Re-uploaded the zip/piccy after DBF server crash
7
Projects / Re: DFGVY ADVERTRO
« on: July 04, 2008 »
That's impressive to get some sound/movement/changing-colours in 256b...and it didn't crap out my PC like some tinies do!
...and thanks for including the assembler source, not that I understand it but I'd like to think I might do one day
...and thanks for including the assembler source, not that I understand it but I'd like to think I might do one day
8
C / C++ /C# / Re: Defining/using Open-GL Camera paths
« on: November 07, 2007 »
Thanks again - and that site seems to have some interesting stuff on it...hope I can absorb some of it!
9
C / C++ /C# / Re: Defining/using Open-GL Camera paths
« on: November 06, 2007 »
Cool, and thanks again - I have a use for this in the texture creation section (and likely to be elsewhere too when I start polishing it) - could the 'fld' in your example code suffer from the same issues under size optimization that the ftol's did? I think I need to read up on assembler over the next few months...if I ever complete this I'll know a stack more than when I started 
10
C / C++ /C# / Re: Defining/using Open-GL Camera paths
« on: November 06, 2007 »
Wow!
Thank you! Thank you! Thank you! Thank you! Thank you! (and K++ of course)
That's an impressive find if you hadn't have found it I might have had to give up on that in time, as I wouldn't have found that!
The native.h was in my previous scrolly Putrid 4K Scroller and it probably went unnoticed because of the nature of how they were used (I'll edit that thread to include the new one just in case anyone uses it!)...I think it was originally Slippy who gave me the header when he kindly optimised one stage of the code - but, of course, I added the two problem methods (from an Internet source somewhere - I sure as heck didn't write them from scratch - waaaay out of my depth!)
Now I can focus on ways to make it look better with less bytes!
Thanks again!
Thank you! Thank you! Thank you! Thank you! Thank you! (and K++ of course)
That's an impressive find
if you hadn't have found it I might have had to give up on that in time, as I wouldn't have found that!The native.h was in my previous scrolly Putrid 4K Scroller and it probably went unnoticed because of the nature of how they were used (I'll edit that thread to include the new one just in case anyone uses it!)...I think it was originally Slippy who gave me the header when he kindly optimised one stage of the code - but, of course, I added the two problem methods (from an Internet source somewhere - I sure as heck didn't write them from scratch - waaaay out of my depth!)
Now I can focus on ways to make it look better with less bytes!
Thanks again!
11
General chat / Re: TOP 5 ALL Around Programming Langague?
« on: November 04, 2007 »
Rain_Storm - I loved working with VB 6 (apart from the monster DLL, its style of classes, and the sneering I got from so-called 'real' programmers) - I could create some polished looking powerful apps relatively quickly with it...I'm not so struck on the .Net flavours of it, but then I've not really given them a fair try as it seems a bit redundant to me...so many good languages and only 5 choices
12
General chat / Re: TOP 5 ALL Around Programming Langague?
« on: November 04, 2007 »
Here's mine, depending on the purpose/mood:
HotShot - AMOS - I lurved it, I think the main alternatives back then were mainly SAS C compiler or DevPac Assembler which are both still too difficult for me! AMOS got me into the gfx double-buffer concepts etc...but what I wanted to do was decent sinus-scrollers like the DevPac guys could, and mine always looked crap in AMOS! That was probably just me though
Shockwave - COBOL - I swear I got RSI from that, man that was a lot of typing from what I remember!
- Java - because it just comes naturally to me now, and there's lots of good references and nearly everything has a Java API
- Freebasic - I've found it relatively simple, portable, but still very powerful...it's what made me discover this website too
- C++ - for when I want a challenge with the language rather than the task (or generally do stuff I shouldn't) - and it's efficient, has lots of good references/resources for it too of course
- C# - because I've done some seemingly good OS-focussed tools for work that really just used the standard libs with my GUI interfaces slapped in front
- DarkBasic Pro - I'm sure Blitz was faster etc from what I've seen in demos, but this is just the one I got familiar with, and it is pretty simple to do some good things. I've never really experienced any bugs with it myself, it just seemed too slow (which was probably my misuse of it)
HotShot - AMOS - I lurved it, I think the main alternatives back then were mainly SAS C compiler or DevPac Assembler which are both still too difficult for me! AMOS got me into the gfx double-buffer concepts etc...but what I wanted to do was decent sinus-scrollers like the DevPac guys could, and mine always looked crap in AMOS! That was probably just me though
Shockwave - COBOL - I swear I got RSI from that, man that was a lot of typing from what I remember!
13
C / C++ /C# / Re: Defining/using Open-GL Camera paths
« on: November 01, 2007 »
Hi Frea,
I'd assumed GLUT was a helper-system to use alongside OpenGL/GLU (e.g. I'm using GLU's gluLookAt command and I didn't think GLUT had an equivalent) - but I'll check it out as it has a handy static-lib build...
...thanks for the pointer!
I'd assumed GLUT was a helper-system to use alongside OpenGL/GLU (e.g. I'm using GLU's gluLookAt command and I didn't think GLUT had an equivalent) - but I'll check it out as it has a handy static-lib build...
...thanks for the pointer!
14
C / C++ /C# / Re: Defining/using Open-GL Camera paths
« on: November 01, 2007 »
Well, if it's a choice between me or Microsoft doing something daft, then I KNOW it's me Although I think the Intel compiler error I mentioned was surprisingly from last year.
It does happen in Debug mode if I enable the size optimization, it's just the data in the arrays is hard to spot by eye when it changes...hopefully the Watch can watch for changes in it (will check this out) so I can see what's corrupting it.
BTW the x and y confusion is probably where I've been moving this code around to try different things and that stuck by mistake - I'll clean that one up
[edit] I think that this was my 25th post so I can finally give you karma for the tons of help!
[edit] Damn...debugging is out of the question because the optimization screws the symbols...but one thing I can see is that the texture array is being populated with duff values when run under size optimization, rather than being corrupted afterwards...the 'colMap' array that the textures derived their values from is being populated with 0's when size-optimized for some reason, and the textures still look the same when I overwrite values in that array anyway...time to look at COD outputs
Although I think the Intel compiler error I mentioned was surprisingly from last year.It does happen in Debug mode if I enable the size optimization, it's just the data in the arrays is hard to spot by eye when it changes...hopefully the Watch can watch for changes in it (will check this out) so I can see what's corrupting it.
BTW the x and y confusion is probably where I've been moving this code around to try different things and that stuck by mistake - I'll clean that one up
[edit] I think that this was my 25th post so I can finally give you karma for the tons of help!
[edit] Damn...debugging is out of the question because the optimization screws the symbols...but one thing I can see is that the texture array is being populated with duff values when run under size optimization, rather than being corrupted afterwards...the 'colMap' array that the textures derived their values from is being populated with 0's when size-optimized for some reason, and the textures still look the same when I overwrite values in that array anyway...time to look at COD outputs
15
C / C++ /C# / Re: Defining/using Open-GL Camera paths
« on: October 31, 2007 »
I appreciate you looking at it Jim - all ideas are very welcome, as I'm running out of them
I tried setting all glBindTexture to use the value from the textureIDs array, as well as the specific one you highlighted, but alas no difference in the output (I've kept these in though because you're still right)...
...I've been trying to find out why size-optimization (/O1 and/or /Os) specifically should cause this texture corruption, but no joy yet.
A version of the Intel compiler for CE had an optimization problem with local arrays >3.5KB and a size not divisible by 4, so I set the texture count to 16 in case VS2005 had a similar issue, but it made no difference...my gut feel is it's going to be something like this, just because it works ok without size optimization, but I'm aware of my inexperience as the most likely cause!
FYI I also found someone having a similar problem with OpenGL on a Mac, but alas a solution wasn't posted:
http://lists.apple.com/archives/mac-opengl/2006/Dec/msg00013.html
I've tried it on AMD with NVidia FX5500 and Intel with ATI X600 and it displayed the same issue, so it's not CPU or driver-based issue...oh and I reinstalled/updated VS2005 out of desperation too
I tried setting all glBindTexture to use the value from the textureIDs array, as well as the specific one you highlighted, but alas no difference in the output (I've kept these in though because you're still right)...
...I've been trying to find out why size-optimization (/O1 and/or /Os) specifically should cause this texture corruption, but no joy yet.
A version of the Intel compiler for CE had an optimization problem with local arrays >3.5KB and a size not divisible by 4, so I set the texture count to 16 in case VS2005 had a similar issue, but it made no difference...my gut feel is it's going to be something like this, just because it works ok without size optimization, but I'm aware of my inexperience as the most likely cause!
FYI I also found someone having a similar problem with OpenGL on a Mac, but alas a solution wasn't posted:
http://lists.apple.com/archives/mac-opengl/2006/Dec/msg00013.html
I've tried it on AMD with NVidia FX5500 and Intel with ATI X600 and it displayed the same issue, so it's not CPU or driver-based issue...oh and I reinstalled/updated VS2005 out of desperation too
16
C / C++ /C# / Re: Defining/using Open-GL Camera paths
« on: October 31, 2007 »
Hi Chris,
Thanks for the tip! The camera_moves are multiplied by WORLD_SCALE, so a position difference of .2 is actually .2*20...but you're absolutely right - those bytes saved (and others like that) are going to be needed for the synth and hopefully other things...all good learning for me (I'm a Java programmer who does non audio/visual stuff by day )
Thanks again!
[Edit] I just tried the camera_moves change, and that change alone saved 1020 bytes in the (uncompressed) debug version, and even 61 bytes in the (compressed) Crinkler release version - so I'll definitely be replacing floats with smaller types wherever possible, as they'll all add up. I'll also replace the unchanging calcs with constants once I've got the finished app in place - at the moment it's easiest to leave them in so I can change stuff easily.
Thanks for the tip! The camera_moves are multiplied by WORLD_SCALE, so a position difference of .2 is actually .2*20...but you're absolutely right - those bytes saved (and others like that) are going to be needed for the synth and hopefully other things...all good learning for me (I'm a Java programmer who does non audio/visual stuff by day
)Thanks again!
[Edit] I just tried the camera_moves change, and that change alone saved 1020 bytes in the (uncompressed) debug version, and even 61 bytes in the (compressed) Crinkler release version - so I'll definitely be replacing floats with smaller types wherever possible, as they'll all add up. I'll also replace the unchanging calcs with constants once I've got the finished app in place - at the moment it's easiest to leave them in so I can change stuff easily.
17
C / C++ /C# / Re: Defining/using Open-GL Camera paths
« on: October 29, 2007 »
Thanks all, I appreciate the responses!
RBRAZ - I originally used a static array buffer, but then I used 64*64 resolution textures and that caused a __chkstk link error because I'd exceeded the stack allowance with the static arrays (I think this is what you meant, but I'm not up on the C++ terms yet)...
...as I'm now using lower-res 16*16 resolution textures you're right in that the GlobalAlloc and dynamic arrays aren't essential...so I've reverted to static arrays, along with removing the OO code and other stuff that (I think) wasn't being used (project attached here with these changes)...and I still have the same texture problem, still only with the MS VC size-optimized builds...it's really odd, so I'll be spending a lot of time reading up on what this setting really changes (any knowledge anyone has about it is welcome!).
BTW I notice my GLU32.DLL has a dependency on MSVCRT.DLL, probably because it's installed with MS VC++, but is there a release that doesn't use MSVCRT? I tried to download it from OpenGL instead, but it seems to be just specs and 3rd-party libraries that I can see I guess it's irrelevant to 4K anyway, because if GLU is accepted, whatever DLLs it uses are accepted too...maybe...
BTW2 I'll try to do something with the scroller so it's not so far away and set the view distance to something more sensible to speed it up...I might pre-render each 3D char with proper lighting etc and capture them as 2D images to use in ortho blended on top of the Fractaland as a standard scroller...depends how many bytes that change uses not an original concept, but all good fun to play with...far more interesting than the day job
RBRAZ - I originally used a static array buffer, but then I used 64*64 resolution textures and that caused a __chkstk link error because I'd exceeded the stack allowance with the static arrays (I think this is what you meant, but I'm not up on the C++ terms yet)...
...as I'm now using lower-res 16*16 resolution textures you're right in that the GlobalAlloc and dynamic arrays aren't essential...so I've reverted to static arrays, along with removing the OO code and other stuff that (I think) wasn't being used (project attached here with these changes)...and I still have the same texture problem, still only with the MS VC size-optimized builds...it's really odd, so I'll be spending a lot of time reading up on what this setting really changes (any knowledge anyone has about it is welcome!).
BTW I notice my GLU32.DLL has a dependency on MSVCRT.DLL, probably because it's installed with MS VC++, but is there a release that doesn't use MSVCRT? I tried to download it from OpenGL instead, but it seems to be just specs and 3rd-party libraries that I can see
I guess it's irrelevant to 4K anyway, because if GLU is accepted, whatever DLLs it uses are accepted too...maybe...BTW2 I'll try to do something with the scroller so it's not so far away and set the view distance to something more sensible to speed it up...I might pre-render each 3D char with proper lighting etc and capture them as 2D images to use in ortho blended on top of the Fractaland as a standard scroller...depends how many bytes that change uses
not an original concept, but all good fun to play with...far more interesting than the day job 18
C / C++ /C# / Re: Defining/using Open-GL Camera paths
« on: October 20, 2007 »
Cheers - you're a star - I KNEW you'd know what the heck I was doing wrong!
I'll change it when I get back, so fingers crossed...might be just one of many bugs in there of course
I'll change it when I get back, so fingers crossed...might be just one of many bugs in there of course
19
C / C++ /C# / Re: Defining/using Open-GL Camera paths
« on: October 20, 2007 »
Hi again,
I haven't been able to spend much time on finishing this (usual real-life stuff getting in the way that we all endure ) but I've added some bits:
Anyway, the purpose of this prog for me was/is as a learning exercise, and there's been stacks of C++/OpenGL learning been done which is why it's taking so long...one such learning curve is that I OO'd it then eventually found that new/delete and memalloc/free link to the MSVCRT.DLL...so de-OO'd it and used GlobalAlloc/GlobalFree instead to avoid the __chkstk errors from my huge static arrays at the time (I haven't implemented my own new/delete routines yet)...which brings me to an issue I'm currently stuck on, and I'm really hoping someone here has some suggestions...
...when I enable the VC 2005 size optimizations, my textures go wrong (compare debug and release EXEs) - they look different...if I make the debug version use the size optimizations it also looks wrong, so I have tracked it to the optimizations specifically. The textures are created in the Shapes.cpp's InitTextures method and are stored using pointer arrays allocated using GlobalAlloc, extract here:
I've tried giving textureStore broader scope by defining it out of the method, also removing the GlobalFree altogether (as in attached source) without any difference...mainly because I figure that if the optimization is affecting it then maybe my texture memory is being seen as available and something is stomping over it, but the corruption seems consistent which kind of shoots that theory really...maybe the optimizations use different data types under the hood yielding different values or something like that?
BTW this is regardless of whether I use Crinkler or not so it's not the compressor trashing data or anything like that.
Anyone come across stuff like this before? I'm away from my computer for a week (not sure how I'll cope) - but thanks in advance for any ideas if you have any!
Correct kind of view (without optimization):
Wrong kind of view (with size optimization):
Apart from this issue the code itself seems to work fine, albeit quite hard going on the CPU/GPU, and I've put as many comments in as I can - in case anyone sees something they want to try and improve on in their own intros...I'm at the 4k limit, so I'll have to start making the code optimizations (i.e. will be unreadable) now to fit stuff in
PS Shockwave - cheers for the mention in the gears intro - I was/am totally gobsmacked!
I haven't been able to spend much time on finishing this (usual real-life stuff getting in the way that we all endure
) but I've added some bits:- (very) basic textures on buildings/grass/water
- rooftops/mounds
- waves...well water movement, hardly realistic motions!
- erm...a scroller...always a scroller...but I've implemented it differently so it's staying in for now
Anyway, the purpose of this prog for me was/is as a learning exercise, and there's been stacks of C++/OpenGL learning been done which is why it's taking so long...one such learning curve is that I OO'd it then eventually found that new/delete and memalloc/free link to the MSVCRT.DLL...so de-OO'd it and used GlobalAlloc/GlobalFree instead to avoid the __chkstk errors from my huge static arrays at the time (I haven't implemented my own new/delete routines yet)...which brings me to an issue I'm currently stuck on, and I'm really hoping someone here has some suggestions...
...when I enable the VC 2005 size optimizations, my textures go wrong (compare debug and release EXEs) - they look different...if I make the debug version use the size optimizations it also looks wrong, so I have tracked it to the optimizations specifically. The textures are created in the Shapes.cpp's InitTextures method and are stored using pointer arrays allocated using GlobalAlloc, extract here:
Code: [Select]
void InitTextures() {
GLubyte **textureStore = (GLubyte**)GlobalAlloc(GPTR,TEXTURES*sizeof(GLubyte*));
for (int t=0;t<TEXTURES;t++) {
textureStore[t] = (GLubyte*)GlobalAlloc(GPTR,TEXTURES*TEXTURE_SIZE*sizeof(GLubyte));
}
...
glGenTextures(TEXTURES, textureIDs);
for (int x=0;x<TEXTURES;x++) {
glBindTexture (GL_TEXTURE_2D, x);
// Texture repeats over both S & R axis so out of range co-ords still get textured
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, TEXTURE_WIDTH, TEXTURE_HEIGHT, 0, GL_RGBA, GL_UNSIGNED_BYTE, &textureStore[x][0]);
}
// Free dynamic array
GlobalFree(textureStore);
}
I've tried giving textureStore broader scope by defining it out of the method, also removing the GlobalFree altogether (as in attached source) without any difference...mainly because I figure that if the optimization is affecting it then maybe my texture memory is being seen as available and something is stomping over it, but the corruption seems consistent which kind of shoots that theory really...maybe the optimizations use different data types under the hood yielding different values or something like that?
BTW this is regardless of whether I use Crinkler or not so it's not the compressor trashing data or anything like that.
Anyone come across stuff like this before? I'm away from my computer for a week (not sure how I'll cope) - but thanks in advance for any ideas if you have any!
Correct kind of view (without optimization):
Wrong kind of view (with size optimization):
Apart from this issue the code itself seems to work fine, albeit quite hard going on the CPU/GPU, and I've put as many comments in as I can - in case anyone sees something they want to try and improve on in their own intros...I'm at the 4k limit, so I'll have to start making the code optimizations (i.e. will be unreadable) now to fit stuff in
PS Shockwave - cheers for the mention in the gears intro - I was/am totally gobsmacked!
20
C / C++ /C# / Re: Defining/using Open-GL Camera paths
« on: September 08, 2007 »
No intentions other than as a learning exercise for me, and that hopefully something in there might be useful/inspiring to someone else.
However, I do want to try and polish it as much as possible in 4K, and when/if I get it done I'll see what you guys think about needed improvements then see what's happening at the time - if there's an appropriate competition I might throw it in, but most likely I'll just showcase it
However, I do want to try and polish it as much as possible in 4K, and when/if I get it done I'll see what you guys think about needed improvements then see what's happening at the time - if there's an appropriate competition I might throw it in, but most likely I'll just showcase it
Pages: [1] 2