smooth animation in a window - not possible?

Thalius · Post by **Thalius** » Mon Apr 23, 2007 2:55 pm

is that about it?

What Kaeru pointed out is that PB is a multiplatform language made for simple usage. The smplicity allows rapid development but doesent optimize for every possible solution, to optimize and handle several things as you like it thats the freedom of a programmer and also should be one of his maintasks.

PB wraps per operating system the existing API functions for maximum compatibility and system-friendlyness ( why reinvent the wheel ? ). Specific PB Functions are handmade ASM which build the base subsystems.
Then there is a distinct differnece between Screens and Windows - while you can set a framerate and use flipbuffers on screens a window is opened on a screen already which has more or less fixed parameters, however the drawing operations on a window work somewhat different. While for example a screen has a constant framerate you can set via SetFrameRate() while a for exmaple windows desktop has a fixed framerate/sync frequency and under windows refreshes as fast as possible ( maximizing cpu usage ) and the only way to limit is is using delay and/or an event-based solution for the drawing operations to just redraw it if it is needed. While Commands like Delay() are a pretty easy way to handle it - their precision isn't exactly what is needed in some cases and that is what for example the timeGetDevCaps_ API command is for as it operates in a higher resolution than the standard Delay() which is a wrap for sleep_() . The Resolution for this commands is given by the Host Operating System, so you will notice that a delay(1) under Windows is roughtly 16ms of delay while under linux it represents indeed 1 ms but that is because of the implementation of the said API commands. So some Knowledge about the Operating System you are writing your Software for is of great help writing stuff "the non standard way" and to evaluate why several things behave different under Windows and Linux for exmaple. That said i have to say some Knowledge about Windows API is necessairy to achieve some tasks under Windows as they were meant to by M$, theres nothing Fred can do about it unless to rewrite the Libraries to handle the functions the same way but also would make things more unflexible and non-system conform - plus generate some bloat. Its the programmers Freedom to implement special stuff themselves and PB gives you all this possibilities and Freedom. For Example using VB under Windows you would be stuck only with WinAPI and without you would barely be able to do anything! Be happy things are implemented as they are because PBs Commands simplify most things you would need alot technical Knowledge to achieve in anotehr Language - lets say C or VB whatever. Using an Engine such as Ogre to draw into a Window is anotehr Story here as the engine does Things like keeping the sync order etc for you, while when your working with drawing commands which are optimized for flexibility and speed you have to take care of the sync yourself according to the target your drawing on ( a Window in your case on a System Screen ).

If it's worth doing, it's worth doing it right.

I totally agree. But to do things RIGHT you need to understand the Platform you are programming for - otehrwise you end up doing things some ghetto patchwork way often resulting in non-standard behaving programs. Blaming is easy, but before doing that try to understand how things work first. people here trying to explain this to you but you seem to have ideas how things should work on your own, try to be more open and listen to people who know.. its nothing wrong with admitting that you dont know how to do some things the "RIGHT" way.

And yes Amiga was/is a TOTALLY different platform with a UNIQUE Screen Managment - Times changed. And some of teh simplest Tasks back then now require a little more Knowledge ( here i go again ) to achieve the same way as you did it back then on a completelly different System - while some of teh methods especially regarding Graphics are in NO WAY native-compatible in the way Windows works.

Hope this made it clear.

Thalius

mp303 · Post by **mp303** » Mon Apr 23, 2007 3:12 pm

Thalius wrote:theres nothing Fred can do about it unless to rewrite the Libraries to handle the functions the same way but also would make things more unflexible and non-system conform - plus generate some bloat.

I guess this is the point where our perceptions differ.

In my world, accurate VSYNC is a basic, natural requirement. When would I not want VSYNC to be accurate?

But in your world, it's considered "bloat".

If PB in general is built on this type of minimalist approach, I guess it's really more like a macro-assembler with BASIC syntax than it is a high-level language. I guess I have a hard time seeing a BASIC compiler as such...

Dare · Post by **Dare** » Mon Apr 23, 2007 3:21 pm

mp303 wrote:If it's worth doing, it's worth doing it right.

Applies to communicating on these forums too, not so?

Anyhow, your call as to how you intend to deal with people. Remembering, of course, that the guy you diss today might be the only guy who has the answer you may desperately need tomorrow.

But it is not a big deal and I am out of here. You have the floor.

netmaestro · Post by **netmaestro** » Mon Apr 23, 2007 3:24 pm

Remembering, of course, that the guy you diss today might be the only guy who has the answer

So true! I let a huge rant fly at him in the OOP thread a few months back

but I don't keep track of such.

Kaeru Gaman · Post by **Kaeru Gaman** » Mon Apr 23, 2007 3:37 pm

mp303 wrote:I guess this is the point where our perceptions differ.

In my world, accurate VSYNC is a basic, natural requirement. When would I not want VSYNC to be accurate?

But in your world, it's considered "bloat".

incredible.

none is blinder than the one who doesn't want to see.

Thalius just explaned the difference between the desktop and a fullscreen,
but it's ok, you manage the perfect fusion of smartass and dumbass.

so just go ahead and write your own OS or whatever you want, have a nice life.

@all
I think I will memenber that nick.
isn't it a small soundmachine you can connect with a synth and control with cubase?

Thalius · Post by **Thalius** » Mon Apr 23, 2007 3:37 pm

In my world, accurate VSYNC is a basic, natural requirement. When would I not want VSYNC to be accurate?

Try understanding the Difference between Windows and Screens - it seems you still havent gotten it. We all try to help, give advice and try to explain the why's - its not to make excuses or anything its simply a matter of facts.

For drawing on Windows VSYNC does NOT apply... but before i get here out of line because i feel i wasted 15 Mins typing the explanation above i leave it be at this point and just give a last time the Advice to understand things first before you go off in your little world where things are all suddenly wrong while for everyone else they are implemented properly ... go on do things "right" your way.... I have tried to explain it but biting remarks also put me out of mood to do so anymore...

Thalius

Dare · Post by **Dare** » Mon Apr 23, 2007 3:40 pm

Heya, the maestro!

* genuflects *

I recall that thread.

Ah well, I'm off to join the other kiddies and play at being a programmer.

Derek · Post by **Derek** » Mon Apr 23, 2007 3:42 pm

Kaeru Gaman wrote:you manage the perfect fusion of smartass and dumbass.

mp303 · Post by **mp303** » Mon Apr 23, 2007 4:22 pm

wow, you guys know some "big words" - I am obviously way out of my intellectual league here.

Brice Manuel · Post by **Brice Manuel** » Mon Apr 23, 2007 4:28 pm

smooth animation in a window - not possible?

Actually, PureBasic is one of the few indie languages that doesn't have problems with smooth animation when running DX in windowed mode. Even on my worst systems, PB's windowed mode looks great.

Keep in mind that PB's commands are also usually cross-platform and designed in a way to work on all supported operating systems.

The main problem I see newbies have is that they do not understand event-driven programming. PB is an event-driven language and Windows is an event-driven operating system. The approach you need is different than what you used in the old days on prePC systems.

Acting arrogant when you don't understand how to properly use PB's commands isn't a good way to approach solving a problem. Ask questions and don't be afraid to learn. People here are usually more than willing to help. Just don't bite the hand that feeds you

Dare · Post by **Dare** » Mon Apr 23, 2007 4:30 pm

Heya mp303, don't sweat it. And be patient - one day some of us may rise to your level.

* goes back to squabble with the other kids *

mp303 · Post by **mp303** » Tue Apr 24, 2007 7:44 am

Brice Manuel wrote:
smooth animation in a window - not possible?
Actually, PureBasic is one of the few indie languages that doesn't have problems with smooth animation when running DX in windowed mode. Even on my worst systems, PB's windowed mode looks great.

well, as said, I've tested on three different (high-end) systems, and it doesn't work properly ... so yeah, it works "pretty well", except that it drops a frame every second or so. Does that not happen in your applications?

Brice Manuel wrote: Keep in mind that PB's commands are also usually cross-platform and designed in a way to work on all supported operating systems.

yes, that's one of my issues - how exactly is this cross-platform if I need some sort of quirky Win32 API-specific workaround to make it work?

Brice Manuel wrote: The main problem I see newbies have is that they do not understand event-driven programming. PB is an event-driven language and Windows is an event-driven operating system. The approach you need is different than what you used in the old days on prePC systems.

thanks for your concern, but I am aware of this. I'm not a newbie, I've been programming for 20 years.

Brice Manuel wrote: Acting arrogant when you don't understand how to properly use PB's commands isn't a good way to approach solving a problem. Ask questions and don't be afraid to learn. People here are usually more than willing to help. Just don't bite the hand that feeds you :wink:

okay, I'm trying not to, so don't take this the wrong way, but ... you're not really helping.

in most other languages, "properly" using a command like FlipBuffers() would involve simply calling it - nowhere does the manual mention having to do some sort of platform-specific workaround to get this command to work properly.

the command works as intended in full-screen mode - why would anyone logically expect it to stop working in windowed mode?

this ought to be a pretty simple command - I honestly don't think it's reasonable to expect every developer to spend loads of time trying to learn about the quirks of the operating system to get a simple little command like this to work.

If you have to learn about every platform's quirks to get a simple command to work, and write platform specific code, what exactly is the point of having a cross-platform language?

using game libraries in, say, Delphi, I've never encountered this problem or had to worry about anything of this sort... of course Delphi isn't cross-platform, but making something cross-platform does not mean simply ignoring the things that don't immidiately work on all platforms, does it?

Brice Manuel · Post by **Brice Manuel** » Tue Apr 24, 2007 10:28 am

so yeah, it works "pretty well", except that it drops a frame every second or so. Does that not happen in your applications?

Not at all, and I test everything on a wide variety of systems, and I need no "tricks" and anything I write runs in windowed mode only.

how exactly is this cross-platform if I need some sort of quirky Win32 API-specific workaround to make it work?

You don't need any tricks, you are just not understanding the differences between full screen and windowed mode and what needs to be done differently for each.

thanks for your concern, but I am aware of this. I'm not a newbie, I've been programming for 20 years.

PB hasn't been around for 20 years, based on the problems you are having, it seems you are a newbie to the gaming aspect of PB.

the command works as intended in full-screen mode - why would anyone logically expect it to stop working in windowed mode?

Because they are two completely different things. In general, windowed mode performs much worse than full-screen.

Full-screen runs in exclusive mode and has fewer messages to deal with. Flip is done via the graphic's card hardware.

In windowed mode, it has to share resources with GDI. There are more messages to deal with. Flip is done via an old fashioned software bit copy, which is slower. To greatly simplify, it could be said that windowed mode is designed to "emulate" full-screen, but as with any emulation, performance is often the cost.

Does the windowed game example that comes with PB work ok for you, and does the windowed version of Paul's Lady Bug game work ok for you?

Both of those run flawless on all of my systems. If those do not work for you, The problems you are describing are likely due to weird settings in video drivers, not using the latest version of the drivers for your video card, or a video card that does not properly support DirectDraw windowed.

However, if those two examples I named work for you, then the problem is your code.

mp303 · Post by **mp303** » Tue Apr 24, 2007 11:11 am

Brice Manuel wrote:Not at all, and I test everything on a wide variety of systems, and I need no "tricks" and anything I write runs in windowed mode only.

really? could you post an example, please?

I tried "Examples/Sources/WindowedScreen.pb" which is implemented in the same way I did - which is also the way it's demonstrated in the manual. And it displays the exact same issue - every second or so, it drops a frame, and it's using almost all CPU.

Brice Manuel wrote:You don't need any tricks, you are just not understanding the differences between full screen and windowed mode and what needs to be done differently for each.

what is it you do differently then? if you're not using the same Win32-API workaround demonstrated here...?

Brice Manuel wrote:PB hasn't been around for 20 years, based on the problems you are having, it seems you are a newbie to the gaming aspect of PB.

not really, I've done some work in full-screen mode - but it's the first time I've had to do any windowed real-time stuff ... (as said, the same commands when running full-screen do not exhibit any problems)

Brice Manuel wrote:Does the windowed game example that comes with PB work ok for you, and does the windowed version of Paul's Lady Bug game work ok for you?

I couldn't find the ladybug example (may not be included in the v4.0 demo, which is all I have here at work) ... as said though, the WindowedScreen example demonstrates the issue, so apparently I'm not the only one to make this mistake. Could you take a look at that example and maybe tell me what's wrong with it?

Brice Manuel wrote:Both of those run flawless on all of my systems. If those do not work for you, The problems you are describing are likely due to weird settings in video drivers, not using the latest version of the drivers for your video card, or a video card that does not properly support DirectDraw windowed.

I've tested the WindowedScreen example on four different systems, all high-end systems with updated Windows XP installations, updated DirectX and latest graphics card drivers. Same deal, on all of them.

Initially, I also suspected it could be a system issue, and I've therefore created a pair of test-movies (AVI format) that you can get here:

http://public.develop.fyens.dk/test_30.avi
http://public.develop.fyens.dk/test_60.avi

The same clips, but in 30 and 60 FPS. Playing them in the old MPLAYER2.EXE and/or latest Windows Media Player, both play back smoothly, on all of my test systems - indicating that it's not a hardware or driver issue.

(note, your screen must be set to update at 60 FPS for this test to really tell you anything)

I also tried playing these movies in the "MoviePlayer.pb" example - they play back smoothly, but I suppose that's because they're being played back by an operating system component? I don't see any calls to FlipBuffers() in that example...

Also, as said, the modified version of the example I posted (with the Win32-API-specific process timing fix) works fine.

So I find it hard to believe that there's something wrong with all four systems I've been testing on, and that for some reason, this only affects PB applications and not other applications such as WMP... that seems a little far fetched?

If there's something wrong with the example I posted originally, if there's some way you can get this to work without the process-timing workarounds, please post an example?

thanks!

mp303 · Post by **mp303** » Tue Apr 24, 2007 11:19 am

@Brice: I saw in another thread that you're using a custom 2D Engine? Maybe your custom engine is why windowed graphics work for you while the examples that come with PB distribution don't even work... Is it available somewhere?