| |
May I ask if you have a minute or ten for me? Displaying 1-20 of 28 total.
12
next
Buckermann
|
It would be greatly appreciated if you would took time to download this file (around 700kb) unzip it, run the "Window Test (10)" from the first menu and tell me your personal opinion about the general speed of it. Do you think it is to slow, or maybe adequate?
If you do so, please post also the speed of you CPU and what GFX card do you have.
Thanks.
(Ps: I don't consider this file as releasable to the public yet. If you use it to anything else than running it, may the gods have mercy with your poor soul. Of course you can try if you are brave enough)
Posted on 2004-05-26 21:40:43 (last edited on 2004-05-26 21:47:40)
|
mcgrue
|
It's generally adequate when fullscreened or non-max windowed.
A pox upon automax! ;)
Also, good job in general! :o
Posted on 2004-05-26 23:00:57
|
Buckermann
|
I'll add you (once again) to the credits, for being the first to answer my call.
...
Done.
Maybe I'll also add the next one to post his opinion...
Also, good job in general! :o
Thanks.
I don't know exactly why, but I enjoy it very much coding such utility functions.
Posted on 2004-05-26 23:20:08
|
RageCage
|
it seems fine, it could probably be optimized a little as it seems kinda lagged on my 1ghz, but not a enough to really amtter all that much. Aso might I suggest an active offscreen condition check for the windows? you probably dont even need an off screen check... I dunno, just trying to comment on something, nice job!
Posted on 2004-05-27 00:57:27
|
Buckermann
|
RageCage,
Yes, it can be laggy sometimes. I too have a rather slow CPU, around 1300 Mhz. But I don't see a way to speed it up substantialy, maybe another 5% or 10%.
The reason is simple, to keep the mouse cursor from leaving artefacts after some window operations I have to use my custom ShowPage() function:
void TB_showpage()
{
TB_Cursor();
TB_UpdateWindows();
Blit (0, 0, BackgroundLayer, screen);
if(DisplayMouse)
tBlit (0,0, MouseLayer, screen);
showpage();
}
The windows/menus are blitted to the BackgroundLayer and the mouse cursor to the MouseLayer. This way you don't have to turn the mouse off every time you wish to draw something to the screen, and again on when you are done drawing. Believe me, I tried that way, and it was really a mess to work with. Sometimes you have to sacrify speed for usability. Just like the real windows ;)
If Verge had a hardware layer for the mouse (or other sprites) I think I could speed the whole thing up by 25%.
Maybe I do also a version without mouse support.
And thanks for your time.
Posted on 2004-05-27 01:47:23
|
geronimo
|
i think the way windows handles redrawing is by indication of Invalidated Rectangles. i.e. the window is told one or more rectangle coordinates sets it needs to redraw. Like when the mouse cursor moves over a window, it would create a 16x16 or something invalidated rectangle. i dunno.
Posted on 2004-05-27 02:40:26
|
el_desconocido
|
Very nice! Speed seems good to me, 2.5 GHz Celeron, 768 MB ram, Radeon 7000 with 64 MB ram.
In fullscreen mode, went a little buggy: mouse invisible in top 20 or 30 pixels, dragging windows would leave chunks of them behind, looks like all you need is to recalculate your sizes/positions on switching vidmode or something.
El Impresionado
Posted on 2004-05-27 02:59:27
|
Buckermann
|
Quote:Originally posted by El Desconocido
Very nice! Speed seems good to me, 2.5 GHz Celeron, 768 MB ram, Radeon 7000 with 64 MB ram.
Thanks for the info.
In fullscreen mode, went a little buggy: mouse invisible in top 20 or 30 pixels, dragging windows would leave chunks of them behind, looks like all you need is to recalculate your sizes/positions on switching vidmode or something.
The invisible mouse in the upper border of the window is just because of the debug info displayed there. If you would like to disable the info, you can set TB_DebugInfo to 0 (zero) in tb_window.vc, at around line 35, and put a // in front of
rectfill(0,0,800,20, RGB(255,0,255), MouseLayer);
at line 463.
The problem with artifacts from the windows should be already fixed (at least on my end). Just a simple timing problem. It was possible that the mouse moved a bit between pressing the left button and starting the MoveWindow function. That could lead to blitting the restore-image to the wrong place, which then left a part of the window on the screen. Now the function stores the mouse coordinates which will be used by the MoveWindow function, instead of the actual mouse position.
[Edit: corrected a spelling error on the request of a certain forum member.]
Posted on 2004-05-27 03:23:56 (last edited on 2004-05-27 11:18:21)
|
Gayo
|
INVINCIBLE MOUSE!
Posted on 2004-05-27 04:05:16
|
blues_zodiakos
|
The translucency effect is probably one of the most expensive (besides rotscale) operations in verge3. I don't know how it will look, but you could always see if AdditiveBlitting the windows would provide a speed boost. So far, AdditiveBlit seems much, much faster (even though translucency and additiveblit are two completely different things). It might provide a semi-translucent effect at faster rate.
Posted on 2004-05-27 12:40:43
|
vecna
|
Another thing I probably haven't mentioned much is that 50% (exactly) lucency is much faster than any other setting of translucency. For most blitters.
Also, the test runs quite fast on my system, but being thats its an Athlon64 3000+ w/ GeforceFX5900, I would certainly have hoped so. :D
Posted on 2004-05-27 13:28:40 (last edited on 2004-05-27 13:32:30)
|
Buckermann
|
I added a switch for the lucency value. Now it is possible to switch between off, 50% lucency and the original custom lucent value for each windowstyle frame/body. This way people with a slower rig (like me) can turn the eyecandy down and get a speed boost.
I also tried additive (and for the sake of completeness subtractive) blitting, but the speed gain was only marginal and it looked really strange.
And thanks for the info Vecna. 
Posted on 2004-05-27 15:24:31
|
Buckermann
|
I have run some automated tests with the window test function:
Full Lucency 50% Lucency No Lucenzy
with mouse support 9/24/2430 10/23/2340 10/22/2301
w/o mouse support 11/20/2105 11/20/2017 11/19/1979
(Average Framerate / Time in seconds according to my framecounter / Time in 1/100 seconds according to the timer)
It seems to me that it is more important, if I wish to improve the speed, to look for a better way to handle the mouse, then to try to speed up the drawing of my windows.
Has anybody ever tried to hook the mouse handling to the HookTimer function?
Posted on 2004-05-27 18:50:28 (last edited on 2004-05-27 18:51:47)
|
mcgrue
|
No Lucency w/o mouse support is like a month older than me!
...
Posted on 2004-05-27 19:41:16
|
Buckermann
|
Quote:Originally posted by mcgrue
No Lucency w/o mouse support is like a month older than me!
Is that a good or a bad omen?
Posted on 2004-05-27 19:50:33
|
rpgking
|
I just ran the demo, and it runs pretty fast when it's in fullscreen or non-automax windowed mode. The mouse movement was a bit laggy though. I'm on a PIII 600mhz.
This was a really impressive window demo though.
Posted on 2004-05-27 22:19:21 (last edited on 2004-05-27 22:20:06)
|
Buckermann
|
Thanks rpgking.
Good to hear that it runs not to bad on your PC.
And thanks again for the compliment. Can't get enough of that :)
Regarding the speed, I'm testing a magical FPS booster. In fact it is more like a placebo. With this it feels like everything is faster. Please have a look at my ShowPage function (especially from //speed hack to //draw the layers):
void TB_showpage()
{
//frame counter
if(timer >= 100+FPS_Check)
{
FPS_COUNT = FPS; //FPS_COUNT are the actual frames per second
FPS = 0;
FPS_Times++; //
FPS_AVG = FPS_AVG + FPS_COUNT; FPS_Check = timer;
}
fps++;
//switch through the different lucent options
if (key[LUCENTSWITCH_1] && key[LUCENTSWITCH_2])
TB_SwitchLucentWindows();
//update the cursor
TB_Cursor();
//general window handling
TB_UpdateWindows();
//speed hack
if (key[SCAN_CTRL] && key[SCAN_GPLUS])
TB_IncreaseFrameSkip();
if (key[SCAN_CTRL] && key[SCAN_GMINUS])
TB_DecreaseFrameSkip();
if(TB_ScreenBlit != TB_Skip_Frames && TB_Skip_Frames)
{
TB_ScreenBlit++;
return;
}
TB_ScreenBlit = 0;
//draw the layers
Blit (0, 0, BackgroundLayer, screen);
if(DisplayMouse)
tBlit (0,0, MouseLayer, screen);
showpage();
}
When setting TB_Skip_Frames to 3 I get a average framerate of about 60!
Of course this is mostly cosmetic. But if the user too thinks it runs faster with this, why not?
Posted on 2004-05-27 23:32:13 (last edited on 2004-05-27 23:33:39)
|
blues_zodiakos
|
Oh my, that's awesome. You've figured out how to make a frame skipper. Together with a frame throttler, some of the people who were looking for a way to have their games run at exactly 60 fps are in luck. Someone needs to make a quick library to make verge run at any arbitrary fps.
-- edit
Of course, the trick is, with a frame skip of 3, you are really functionally only getting 20 fps. :D
Posted on 2004-05-28 14:44:54 (last edited on 2004-05-28 14:46:44)
|
Buckermann
|
Quote:Originally posted by Blues Zodiakos
Of course, the trick is, with a frame skip of 3, you are really functionally only getting 20 fps. :D
Pffft. That are some unimportant trifles. :)
But it really speeds the general flow of the program up. With every frame skipped I get roughly 15% more (on my slow PC) CPU time to do some other things. I admit, with a simple, mostly graphical related application like my windows test, this isn't the best solution.
But I can imagine a program that does a lot of stuff in the background, without constant graphical feedback, would benefit from it.
Maybe something like RageCage execellent A* pathfinding.
Posted on 2004-05-29 03:36:21
|
Omni
|
I think I've tried something like this, and I assume it works by updating the screen only when the FPS isn't lagging behind. Right?
Well...wouldn't it be better to skip all rendering, not just screen updating?
(I'm assuming you're rendering your windows...somewhere else.)
Haven't actually tried your demo yet, but I will. I'm trying to make my own window system in Python--thus learning more about custom window systems is good--plus your screenshot looks neat.
EDIT:
Okay, I've tried it. Your window focusing is amazing. I haven't checked the code, but you make it look so simple. Mine is really...well, it works, but not good. And I'm using OOP. What you've done looks great.
One minor thing: mouse/window collision seems to be based on the entire mouse rectangle. This means that even if a Window is protruding from beneath another, unless the entire mouse rect can fit inside the rect, you can't focus the window. In my system I use check for a 1-pixel wide rectangle at the top-left pixel coordinate of the mouse.
Posted on 2004-06-03 05:17:46 (last edited on 2004-06-03 05:26:36)
|
Displaying 1-20 of 28 total.
12
next
|
|
