Messages

  That is excellent - loved it!

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 

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?

I meant to mention that - I've replaced the download at the top of the Thread with the new (and hopefully working one), cheers!

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 

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

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

Thanks again - and that site seems to have some interesting stuff on it...hope I can absorb some of it!

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 

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!

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 

Here's mine, depending on the purpose/mood:

• 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!

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!

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

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 

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.

[I still have the same texture problem]

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

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

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:

• (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 Expand


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!

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