Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Cliff3D

Here's an improved (more accurate) version of the earlier flowcharts. It should be noted, however, that the "Copy backImage over BackBuffer" process and the "Clear BackBuffer" process MIGHT actually be the same process, but "Clear BackBuffer" simply uses an all-black background image to perform the "clearing" operation (this seems fairly likely given some of the wording in the help file).

[attachment deleted by admin]
It should be noted that my concern about whether there is ACTUALLY any significant time saving to come from what we've been asking for (the ClearScreen -1 request, anyway) is this text from the help file:

QuoteWhen SHOWSCREEN is called, the Back Buffer and Primary Surface are swapped. The now unusable Back Buffer will be replaced (cleaned) with the Offscreen Surface which is black when no bitmap is loaded.


If you don't see any result from your program, the first thing to check is whether you have forgotten to add the 'SHOWSCREEN' command to it.
Think of Double Buffering as two sheets of paper, one on top of the other where you draw on the bottom sheet. Once you're finished drawing, you swap the sheets and in the process erase the new bottom sheet. This hides the actual drawing of the sheet from the user and in the process eliminates screen flicker.

Now it CAN be dangerous to read too much from small words or even sentences, but there is an implication that the BackBuffer and FrontBuffer are somehow "swapped" rather than just copying the BackBuffer over the FrontBuffer. If indeed the BackBuffer is "simply" copied onto the FrontBuffer then there is much more room for a "ClearScreen -1" type command to save significant time for certain types of App. It would certainly help some aspects of code I have been writing, which is more vector-based than sprite-based, and would benefit from being able to display tiny single-triangle updates more quickly. Of course, being able to draw directly onto the FrontBuffer would be better still for MY code - but it seems this is not possible in GLBasic for multi-platform compatability reasons.
Quote from: ampos on 2010-Oct-28
The fact is that it opens a new entry way for my app to be faster on old iDevices  :good:

Possibly - at least it is the hope, but it depends somewhat how SHOWSCREEN actually WORKS as to whether there is significant room for improvement.

At it's simplest, I imagine SHOWSCREEN does something like the first flowchart here, although obviously the second flowchart would be more efficient when there is a static background image being used (even if that "static" background image is changed every frame by the App, as can be done).

HOWEVER, there is much that is left unclear in these flowcharts - each step could do with being better defined. For example, if the step "Swap BackBuffer and ForeBuffer" involves copying the contents of the BackBuffer to the ForeBuffer then the state of the BackBuffer afterwards is well known and potentially useful (and so having a way to NOT clear it would be great). If, however, the process involves assigning a "ForeBuffer" pointer to the BackBuffer and creating a new BackBuffer memory block, and pointing the BackBuffer pointer at this new memory block, then the contents of the Backbuffer is unknown and removing the "Clear BackBuffer" process from the procedure would not be as helpful as might otherwise be imagined.

Additionally it would be interesting to know if the FrontBuffer (oops I named it wrong above) is the actual display, or if it is indeed a buffer that is copied to the ACTUAL screen display at the termination of the SHOWSCREEN command. I get the impression that the FrontBuffer is the ACTUAL display memory, but I am not 100% positive.

[attachment deleted by admin]
This is one reason that i am hesitant to produce any kind of flowchart that is anything but overly generic to show "how screen updates are done" becuase the fine details - which may be platform specific - could disagree in specific situations with a flowchart. Without being privvy to how and why some routines are slower than others it's a tough call on how and why different scenarios are faster or slower.

In theory a sprite SHOULD IMHO be faster than Polyvector, because a sprite that matches the background dimensions pixel-for-pixel should be a very swift, optimised copy that POLYVECTOR can't compete with because POLYVECTOR has to be able to cope with non-exact size and shape matches. BUT - this can be made "untrue" either by harnessing the GPU for POLYVECTOR and not sprites (so memory accesses are almost all on the graphics card, not having to cross busses to the CPU) for example, or by having sprite code simply being older and unoptimised than the POLYVECTOR code. Examples only of how, on some platforms, sprites could be faster or slower than polyvector.

Why or how the existing "background image" code could perform slower than using a sprite is a mystery to me, as one would have thought that the "background image" would have the most efficient code possible because it has the most certain direct 1:1 correlation, in size, between the background and the backbuffer. It FEELS as if, perhaps, sprite handling has been given some optimisation over the years that the background image copier hasn't. I'd have thought it possible for the background image to be AT LEAST as fast as a sprite (by reusing the same technique/code) if not faster (by optimising based on the background being held in memory as the same dimensions as the backbuffer) but that would require more dev time from Gernot (or perhaps an efficient method of cloning Gernot!)
Quote from: matchy on 2010-Oct-28
Oh. I didn't realize that LOADBMP stays in the fore-buffer.   :zzz:

Well technically it probably replaces the background image buffer, in much the same way that "UseScreen" can redirect drawing to a sprite instead of the usual backbufffer:

QuoteLOADBMP bmp$

Loads the file bmp$ and changes the background image buffer to the image. As a result, it will form the background for your program's display from the next call to SHOWSCREEN.


Probably the key word there is "from". Often the implication of commands (in many language) hinge on the tiniest of words in the definition, and I usually miss them completely.

If no-one does so before I get home in a few days time, I might be tempted to draw up a few flowcharts of ways that GLBasic's screen updates might currently be happening - but they would be based heavily in conjecture (for example, when there is a background image, does Gernot bother clearing the backbuffer before copying the background screen over it? If the background image supports alpha/transparency then it probably needs a clear screen beforehand, if it doesn't then that step would seem to be not required). And so on.
Quote from: matchy on 2010-Oct-28
I'm terribly confused about this thread. Could someone post some example code to display (and keep) a static background image, sprite or bmp file the most efficient way plzzzz!!!1!!11 :whip:.

ampos's response is quite correct and most helpful, but I'd like to add "you're probably confused in part because this thread is NOT about the most efficient way of having a static background, but about making having a dynamic background more efficient".

For example, if we could time our Apps to the "screen refresh" pass, we could (in theory) time our screen drawing directly to the screen memory with no snow or tearing or anything.

Now, I don't know the exact internals for how screen handling works in GLB for every device, but there are several steps taken (copying from backbuffer to frontbuffer, then clearing the backbuffer, then potentially copying the static background to the backbuffer) which have a number of effects:

1. It keeps the "ACTUAL screen update" as fast as GLB can possibly manage, which should avoid all snow and/or tearing.

2. It adds processing to do all those jobs, which might not be necessary for some Apps*

3. It wipes the drawing "to date", which may actually mean the App coder has to redo masses of work, further slowing the App.

What we're looking for is to increase the performance of Apps which don't need - or want - the background clearing and rebuilding each and every frame. The "ultimate" of this would be to be able to draw on the screen directly, but in some instances this can cause screen tearing. So you can see why Gernot might be qnti this, as it could cause support issues for those who don't understand screen technology very well. A compromise situation is to not clear the backbuffer when it's copied to the frontbuffer. How Gernot achieves this would depend on the actual techniques used to "swap" and clear the buffers on each platform, but the theory is to reduce the CPU/GPU overhead on screen updates.

Quote from: Sokurah on 2010-Oct-27Aww man, I'm pretty sure that when I've finished the 3 glowy-vector games I have in development I don't want to see another one of those for a long while. :D

:-[ Sorry! I'm both new and unobservant. Let's forget I ever suggested glowy lines eh?  :good:
Quote from: Ian Price on 2010-Oct-27It's horses for courses. Although if you only played the pc version, I can understand why you enjoyed Repton more. You need to play the original BD on Atari, C64 or CPC - they rock (literally!).

BTW All the later official BoulderDash games (after Construction Kit) suck monkey balls. They are all horrible. The most recent example on the DS was an abomination. So it's only the first 4 games I enjoy (and the last one is the Construction Kit).

Alas, I've never had a C64 that I can recall, and haven't had much experience of the others either. So I've probably just played the "sucky"port :(

I'm mildly tickled about the construction kit comments though, because the soul got sucked out of repton with its construction kit too - I can't recall whichj release it was (may have been as early as repton 3, though I THINK it was later) but it suddenly became a sludgy, unresponsive cheap clone of itself IMHO :(

I think one thing we can easily agree on is that some people can differ in taste without getting into arguments like the wars that rage between Apple / Microsoft "fans"  ::)
Quote from: ampos on 2010-Oct-27
I am nit sure Burnett flicker effect is no more on LCD screens...

But if you have an option you can use it or not. But if you have not an option, you are limited to a single way, for the good or the bad.

You can certainly get a "tearscreen" effect :(

HOWEVER - I cannot agree more on flexibility. If you have 3 alternatives (say) then you have choice and can do what is best for your appv -vif you have only 1 way then there are no options. There are instances where each possible technique has its advantages.
Quote from: Ian Price on 2010-Oct-27
Quote from: Cliff3D on 2010-Oct-27
Oooh, I'm a cynic!

Indeed, but it's not particularly good relations to allow a user to pay for and download an app that isn't compatible with their device. Not that Apple give a toss about such things; they're like Bob Geldof - "Just give us your f###ing money!" :P

Or "well, if it doesn't work when you hold it like that - don't hold it like that!". In the long term it's not great PR, but they will probably try and spin it in their favour if/when they do add such a feature - and probably blame the backlog of uncategorised apps as a problem which prevents them from adding the feature in the short term :(
Personally I think Snowland would fare much better now if held back for release until December - see Kitty's comment elsewhere that the first day or two of release sees whetehr a game SELLS or slinks into the undergrowth - I PERSONALLY would hold back and give it the best push I could in December.

Quote from: Kitty Hello on 2010-Oct-27
OT: What's the difference of BoulderDash vs Repton?

Mostly subtle - on paper there isn't much difference that I've noticed (I would have to get Boulder Dash on a PC again, and at present it is on 5.25" floppies some 200 miles away from my current location). It's like the difference between manufacturers of chocolate - some people really love Cadburys, some (like my wife) prefer Galaxy, while others couldn't care less (either loving all chocolate, or none).

It MAY well be "what you were subjected to first" syndrome - as I encountered Boulder Dash far later than Repton, I prefer Repton. Perhaps ian played BD first and so prefers that. The only counmter I have to that is that my wife played BD first (probably on the C64, long before she met me) and she prefers Repton - but that could be simply because, having got together with me, Repton was much more aqvailable for years.

I've tried the PC Repton remake and, personally, I haven't enjoyed it as much as I enjoyed the original BBC versions - either on a BBC or under emulation. The update somehow makes it feel (to ME personally) like a cheap clone rather than the original. I don't know whether it's the updated graphics, the updated sound, or the gameplay - I suspect there is a subtle gameplay difference in gameplay, in the way the character responds to keypresses. But I'd have to investigate to find out and... yup, 200 miles away!
Quote from: Ian Price on 2010-Oct-26APPLE should be making it clear, by allowing the author to state (via tickboxes if necessary) which machine the app IS compatible with.

You are, of course, quite right, but.... Apple takes a chunk of each sale, doesn't it? So a compatability chart might - in the short term - restrict it's income?

Oooh, I'm a cynic!
Quote from: Sokurah on 2010-Oct-26
I wish I had an idea for a game. I'd get right on it, but good ideas are hard to come by.  :(

Why not make a Repton (boulderdash) style game? Repton - on the BBC Micro at least - surpassed the original because of the addictive music and well-designed levels plus very responsive action 9the controls were VERY responsive without requiring the player to be pixel-perfect). I loved the early Repton games :)

Or take an old vector-based game 2D and make it 2.5D with glowy echoes, a step beyond the likes of "Echoes" or "Geometry Wars" - taken one evolutionary step a step further. I kinda like Scramble to taking Scramble and enhancing it to 2.,5D and glowy or 3D even might be interesting.


Ideas are easy. Good ones, however, are harder. Perhaps look at which arcade games did really well on releqase ages ago and are worthy of being inspired by to produce something much more modern?
At there's a really helpful post about a flow diagram program (free!) which might help find where the problem in your logic is. I'm stuck on a netbook at the moment which is not the very best for studying someone else's code on :( but based on previous posts it looks like you're not fully "getting" the way you need to pull the 3D model, the concept of an array of marker positions, the keypresses, and a disply loop (that displays the aircraft/doughnut, all previous X marks, and the current "floating" X mark) together.

I doubt I could draw a good chart using this screen either, but here's my thoughts in a "level at a time" manner.

First you have to decalre all your variables and set them to useful/default values.

In the outside / main loop you should display your main model. If any X's have been set you should display those. If an X has been activated but not fixed in place you should display it (differently to fixed X's IMHO).

Within the loop, either before or after displaying, you should check for keypresses. If the key is "make an X" then increase the number of X's, set the initial position of the new X.

ELSE If the key is a "move X" key then change the position of the current/last X mark.

ELSE If the key is a "set X position" then deal with that event (may be the same as the "create new X key, in which case this doesn't need writing).

ELSE If the key is a camera movement key then move the camera.

At the moment, although this may be partly because I can see so little code at a time on this tiny screen, I can't see how you are displaying all the pre-set X's as you think about setting a new one. Apologies if it's all present and correct and I am just failing to see it :(

A flowchart might be easier to study, and might enlighten you as to where things are going wrong as you create the chart anyway :D
IMHO ANY method of reducing the number of times that and entire "screenworth" of data gets coppied around would be an improvement.

Quote from: ampos on 2010-Oct-22
If you dont clear the background, you can not draw moving sprites, just add statics ones.

It may not work in your program, or could get too complex to actually save time, but a couple of methods have been used to address this in geenral. One has been to perform some math that negates the screen at a point to produce the dot - and then negate it again to remove that dot on the next path. The other general technique I've seen is to store the color under a dot before you place it, so you draw only the background dots that you have obliterated on the next pass around. Either of these basic ideas might be adaptable if "Don't clear the back buffer" is adopted.

Even if "don't clear the back buffer" doesn't fix this specific issue, it would be an important improvement to the screen handling capabilities of GLBasic. IMHO.