pouët.net

Mousecursors in 4k Intros

category: code [glöplog]
Quote:
And while we are at topic of sync, care to share ideas of what do you use to prevent this 3 frame bufering?

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

:-/
added on the 2012-08-22 15:32:26 by Blueberry Blueberry
care to elaborate blueberry? perhaps in c?
added on the 2012-08-22 17:58:37 by xTr1m xTr1m
well, looks like a fixed sample/time delta to me :)
added on the 2012-08-22 20:53:43 by gopher gopher
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).
added on the 2012-08-23 16:16:41 by las las
In case of doubt I'd vote for the 4k that is able to hide the mouse cursor.
added on the 2012-08-23 19:38:30 by Parasight Parasight
Code: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!)


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)
added on the 2012-08-23 20:39:39 by iq iq
Quote:
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!

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!
added on the 2012-08-24 10:27:42 by Blueberry Blueberry
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.
added on the 2012-08-24 13:55:18 by las las
:D
added on the 2012-08-25 09:53:44 by xTr1m xTr1m
;)
added on the 2012-08-26 03:04:25 by skarab skarab
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.
added on the 2013-08-29 09:54:59 by las las
What about simply moving the cursor at bottom right of the screen or changing the appereance to something totally transparent ?
added on the 2013-08-29 10:01:07 by Tigrou Tigrou
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.
added on the 2013-08-29 10:10:26 by las las
Or set the window's cursor to a void image? Just brainstorming.
added on the 2013-08-29 10:10:29 by xTr1m xTr1m
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.
added on the 2013-08-29 10:13:42 by las las
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 ;)
added on the 2013-08-29 13:08:42 by las las
humm, maybe it was the lack of some update, or *shrug* a virus scanner
added on the 2013-08-29 13:11:34 by skomp skomp
read as "some additional software that should not have been on a compo machine"
added on the 2013-08-29 13:12:14 by skomp skomp
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.
added on the 2013-08-29 13:19:37 by las las
well, if it was the mirc 4k all the discussed workarounds don't work anyway :D
added on the 2013-08-29 13:29:50 by skomp skomp
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.
added on the 2013-08-29 13:36:23 by las las
i can confirm that it works in my setup, and in fell's as well.
added on the 2013-08-29 13:51:14 by skomp skomp
Without it - it should show something like a rotating circle after ~5 seconds. Can you also confirm that behavior?
added on the 2013-08-29 14:15:27 by las las

login