pouët.net

add dword [esp+1*4], 2048*4

:-/

care to elaborate blueberry? perhaps in c?

well, looks like a fixed sample/time delta to me :)

in 4ks i dont care!
in 64k i would care!
but not in 4096 lousy bytes!
fuck the mousecursor (everyone is able to move it offscreen still!)
fuck timing-issues (just try avoiding them atleast! 4klang does that for you.)
even with crinkler removing most of the PE-Header and smallest setup, we still waste way too many bytes on setting up a stupid window to render on already, so i dont waste any additional byte on unneeded features! you always can have a final-version with Resolution-Dialogue etc, which also has those additional features! (as long as you have a working <4096b-version of the same intro next to it!)

Well hardy - those things are "nice to have features" - and they are pretty low cost, sizewise. If I can have those - I would favor all those features over some lame default font crap rendering "TRSI" "hardy" etc..

Btw. I "measured" the "cost" it was around ~4 compressed bytes... And I might have found another thing that gave me 1-9 compressed bytes (depending on the context, we're still checking compatibility - but it seems to be nice.).

In case anyone is not able to hide the mouse cursor with the provided code in 4096 bytes and your intro is <= 4096 bytes without that one PeekMessageA call, I'll help you doing it (In case you trust me enough to give me the source/toolchain + the deadline is not in 60 minutes - having >=1 day is cool).

In case of doubt I'd vote for the 4k that is able to hide the mouse cursor.

i strongly disagree. a 4k intro ahs to be a robust 4k intro, not a zip with crappy 4k coding exercise plus a 20 kilobyte demo. if yo cannot make 4k intros, then don't make them, just go for 64k. if you think you can do 4k intros, then make them proper, robust and good looking. in fact, i think hiding the mouse cursor should be mandatory, just like the ESC key ("hey dude, anybody can open the task manager and kill the intro anyway"), and and having a good timing is crucial. i don't see how sparing some extra 20 bytes is a problem. if you need those 20 bytes, well, optimize your code (or remove that last greet. done)

Yeah, we waste more than half a kilobyte on stupid Windows boilerplate, and we only get a lousy handful of graphics and sound APIs in return. It's not fair!

1. Write a virus, with the typical 4k's boilerplate code as its payload. Throw-in a few things like ray-marching primitives and a synth
2. Infect 99.9% of the potential audience
3. Call the virus payload from your demo
4. TEH ULTIMATE 1337^2 4K

5. never visit a demoparty again.

:D

;)

Hi again.

At demodays 2013 we had to notice that the proposed "fake solution" might not work on all Win7 configurations.

I suspect that some random windows update once again changed the "the application is not handling messages anymore properly" detection.

The combination OpenGL & "tiny mainloop + fake msg handling + esc/asynckeystate" might still cause the cursor to be show under certain circumstances (Which we are not 100% sure about).

From some experiments I'm pretty sure this happens "faster" when vsync is disabled in the driver. It would also be interesting whether this only happens on NVIDIA setups.

What about simply moving the cursor at bottom right of the screen or changing the appereance to something totally transparent ?

Well, SetCursorPos(x,y) might be something to try... But it's not a so nice solution and setting it to something transparent might just not work (SetCursor(NULL) should do the job, but well - it doesn't).

The cursor visible comes from the "the program is not responding anymore" dialog window, so preventing that thing to popup in the first place should solve the problem.

Or set the window's cursor to a void image? Just brainstorming.

I'm pretty sure that will exactly change nothing.

First I need a setup where stuff is broken once again...
Somehow the demodays orgas managed to break the current workaround.

Well just tested some things...
At least on all machines I tried - the PeekMessageA workaround still works properly.
Well - maybe one should just handle the messages properly ;)

humm, maybe it was the lack of some update, or *shrug* a virus scanner

read as "some additional software that should not have been on a compo machine"

Well, maybe even another entry still running, causing this appcrash window to be shown.

According to:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633526%28v=vs.85%29.aspx
and
http://blog.excastle.com/2005/08/15/telling-windows-were-not-really-not-responding/
calling PeekMessage is exactly the right thing to do. So maybe that was some kind of false alarm and the workaround is still working.

well, if it was the mirc 4k all the discussed workarounds don't work anyway :D

Because everyone cares about mirc now? Sure... ;)

Well, we have some suspicions but we definitely need to reproduce whatever happened at demodays - just to make sure it does not happen again.

I currently consider the PeekMessageA(0,0,0,0,0) as still working.

i can confirm that it works in my setup, and in fell's as well.

Without it - it should show something like a rotating circle after ~5 seconds. Can you also confirm that behavior?