Menu

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

#16
Quote from: spacefractal on 2017-Mar-13
Fake positive?

It's taken a little to-and-fro with Symantec, but they have confirmed it as a false positive (unless/until they are proven wrong) and will whitelist this copy of GLBasic in future. The update to make that happen isn't through yet, but should be within the next 24 hours.

Interestingly, they also provide a mechanism for a developer to get their own software whitelisted "in advance", if Gernot is interested.

Cheers,

Cliff3D
#17
Quote from: spacefractal on 2017-Mar-14
there was no glbasic v13.

I saw that and thought of hotels! (They often have no 13th floor due to superstition)

Quote from: spacefractal on 2017-Mar-14Also with v12, Gernot did released the source code, that possible for me to port it to iOS64 with some help. Also im should update SDK etc (to Android 6.x) and port it to that.

I have often thought that it would be most interesting to have GLBasic features (like the editor) written in GLBasic - because then any improvement could quickly be compiled on (and for) any supported platform.


Quote from: spacefractal on 2017-Mar-14Also im are note sure how to compile those SO files on Android, so we can use 64bit and other CPU's. this is not to been talk in this thread at all of course.

But welcome back.

Thanks for the welcome back - and don't worry about going slightly off topic for a thread - I am generally interested in all sorts of stuff, and it's better not to be too harsh on a little meandering.

Android is of particular interest to me, even though it looks like Google favours their Chrome OS going forward. Still it would be nice to be able to dev for Android phones and tablets.

Cheers,

Cliff
#18
Basically it's a very simple Wavefront .OBJ loader and viewer. I'm trying to get back to my experiments to see if I and GLBasic, together, can do certain specific tasks in relation to such 3D models.

For all I know GLBasic can load Wavefront .OBJ models now anyway and my reader/loader is redundant!

Cheers,

Cliff
#19
Quote from: spacefractal on 2017-Mar-13Some anti virus have sometimes giving false positive.

Agreed, but sometimes their algorithms presumably catch true positives, which leaves cautious fellows like me in a difficult position.

I have reported GLBasic as a false positive to Symantec. Whether they actually investigate, and whether they do anything about it if they DO investigate, is out of my hands - but I can HOPE that they amend their software to see GLBasic as the positive force for good that it is.

Cheers,

Cliff
#20
Quote from: r0ber7 on 2017-Mar-13
Welcome back!

=D

Thanks! It's good to be back. I kept missing my little GLBasic experiments.... but where did the time go? V 14? Seriously????  :S

Cheers,

Cliff
#21
Probably, but I am a cautious fellow. I'd prefer not to run something identified as a danger, for preference.
#22
Thanks spacefractal. I am indeed trying to use the demo version - the code compiled fine under the V8 demo although once/if it hit the OGL 3D code it would only last for a little while before closing.

I have tried updating - the result is that the 19 day old GLBasic editor (v14.40100) is now identified by Norton as Trojan.Gen.8 :(

Ulp! :(

Cheers,

Cliff
#23
Hi - after a long time away I'm trying to return to GLBasic. Finding version 8.078 to be a little flaky/intermittent on Windows 10 64 bit I thought I'd update to a newer version - 14.001 specifically.

Now, not unexpectedly, I am finding that there have been changes between version 8 and version 14 (no, it's true!) and on trying to recompile my pretty small program I am getting a bunch of warnings and a fatally uncompiled program. Since at the end it says:

*** FATAL ERROR - Please post this output in the forum

I thought I'd try and post an edited version of the warnings and ask for help. So, I get something very much like...


_______________________________________
*** Configuration: WIN32 ***
precompiling:
GPC - GLBasic Precompiler V.10.037 SN:30a82950 - 2D, WIN32
"ReadOBJ.gbas"(156) warning : GPC1003 Demo mode: This command would require "GLBasic SDK premium"  : X_OBJSTART
Wordcount:715 commands
compiling:
In file included from C:\Users\cliff\AppData\Local\Temp\glbasic\gpc_tempg.cpp:2:
C:\Users\cliff\AppData\Local\Temp\glbasic\gpc_temp.h: In member function `virtual void __GLBASIC__::Facet3D::dbg() const':
C:\Users\cliff\AppData\Local\Temp\glbasic\gpc_temp.h:78: error: ambiguous overload for 'operator+' in 'DGStr(((const char*)"VIndex:")) + ((const __GLBASIC__::Facet3D*)this)->__GLBASIC__::Facet3D::VIndex'
Q:/Compiler/platform/Include/glb.h:278: note: candidates are: __GLBASIC__::DGStr __GLBASIC__::operator+(int, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(int64, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(float, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(double, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, int) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, int64) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, float) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, double) <near match>
C:\Users\cliff\AppData\Local\Temp\glbasic\gpc_temp.h:79: error: ambiguous overload for 'operator+' in 'DGStr(((const char*)"VTIndex:")) + ((const __GLBASIC__::Facet3D*)this)->__GLBASIC__::Facet3D::VTIndex'

and so on and so forth

Q:/Compiler/platform/Include/glb.h:278: note: candidates are: __GLBASIC__::DGStr __GLBASIC__::operator+(int, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(int64, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(float, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(double, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, int) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, int64) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, float) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, double) <near match>
C:\Users\cliff\AppData\Local\Temp\glbasic\gpc_temp.h:566: error: ambiguous overload for 'operator+' in 'DGStr(((const char*)"smoothgroup_Str:")) + ((const __GLBASIC__::OBJModel*)this)->__GLBASIC__::OBJModel::smoothgroup_Str'
Q:/Compiler/platform/Include/glb.h:278: note: candidates are: __GLBASIC__::DGStr __GLBASIC__::operator+(int, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(int64, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(float, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(double, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, int) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, int64) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, float) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, double) <near match>
C:\Users\cliff\AppData\Local\Temp\glbasic\gpc_temp.h:574: error: ambiguous overload for 'operator+' in 'DGStr(((const char*)"Bitmap_Str:")) + ((const __GLBASIC__::OBJModel*)this)->__GLBASIC__::OBJModel::Bitmap_Str'
Q:/Compiler/platform/Include/glb.h:278: note: candidates are: __GLBASIC__::DGStr __GLBASIC__::operator+(int, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(int64, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(float, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(double, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, const __GLBASIC__::DGStr&) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, int) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, int64) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, float) <near match>
Q:/Compiler/platform/Include/glb.h:278: note:                 __GLBASIC__::DGStr __GLBASIC__::operator+(const __GLBASIC__::DGStr&, double) <near match>
*** FATAL ERROR - Please post this output in the forum
_______________________________________
*** Finished ***
Elapsed: 8.4 sec. Time: 11:52
Build: 0 succeeded.
*** 1 FAILED ***


Although my project includes two source files, without references to which source file and/or what line I'm currently stumped. Any suggestions to speed me on my way?

Cheers,

Cliff3D
#24
These old eyes of mine aren't what they once were, and I'd really like to be able to increase the font size and have the printout reformatted - do I have to print my listings using somehting else to achieve this, or is there A Way to get GLBasic to format my pages with larger text?

Thanks :)
#25
Everyone is self-interested, therefore everything done which acts against them - in ANY way - is irritating.

Just now there is concentration on airprot security. Some want to relax security which hampers and irritates legitimate good-guy passengers, while the current security scare on cargo suggest that LOWERING security anywhere would not be a good idea.

It's all about balance, but whenever someone is inconvenienced they will not LIKE it - that inconvenience should, ideally, be aimed only at the people that we need protecting from. Absurd, impossible, but a very natural and (kinda) reasonable attitude IMHO. That doesn't make people anti-Apple, or anti-air companies, or anti-anyone except for anti-inconvenience. There's usually - always? - a way that the inconvenience could be reduced... but that doesn't mean that it will be considered financially practical (Apple keep their costs lower by not employing more people to review Apps, for example). People's natural inclination when they don't like something is to say so :) but that doesn't mean they are "haters" :)

Oh, how nice would it be to have a world where we didn't need any "security measures"? :D
#26
Quote from: Kitty Hello on 2010-Oct-29many games overdraw the whole background with animated stuff. Here, a glClear is not needed.

Agreed. A CLEARSCREEN -1 capability would be nice for these situations :)

Quote from: Kitty Hello on 2010-Oct-29I use the flip on iDevices

A shame. While it seems unlikely, it would always be nice to discover that a small change might result in a large speed improvement ;(

Quote from: Kitty Hello on 2010-Oct-29and try the fastest output possible on all devices. Test it, GLBasic really is fast. Often faster than SDL. Especially blitting.

No doubt - indeed, many of my posts in this vein have been warnings that due to this or that, we might not get the speed improvements that SEEM "obvious", because it seemed likely to me that you would have fairly optimised code, and that "obvious" solutions might not, in the end, provide such improvements :(

Quote from: Kitty Hello on 2010-Oct-29Do not rely on what's on the back buffer after a flip. It also depends on what the driver does. There's no definite way of telling.

This is the saddest thing :(

Quote from: ampos on 2010-Oct-29
But way is faster to draw a full screen sprite than loadbmp?
Quote from: Kitty Hello on 2010-Oct-29
no. Loadbmp does exaclty that. But! When you draw an animated background, you don't want the clear.

Ian has done tests  which suggest otherwise:

Quote from: Ian Price on 2010-Oct-28
Quote from: ampos on 2010-Oct-28
loadbpm "my static background.png"

Actually, a simple test appeared to show that this is  actually the least efficient way to display a background on my laptop. Using a standard sprite proved best for me.

I've included my test (.EXE and code). Maybe the test is flawed, but there's a significant difference between the four tests.

Perhaps there is some flaw in Ian's testing (perhaps you could check his tests):

http://www.glbasic.com/forum/index.php?action=dlattach;topic=5258.0;attach=2496

but otherwise there seem to be some odd differences in speed between certain methods, and a sprite appears to be faster than using a background image :( We'd love to know why/have background images sped up :D
#27
Quote from: Kitty Hello on 2010-Oct-28And here is the "undefined" parameter.
Paraphrased: Sometimes it's a pointer swap, sometimes it's the whole screen copied, depending on the platform.

I had a horrible feeling you were going to say that. So on some devices we could be looking at a modest speed improvement :( (though many a mickle makes a muckle/every little bit helps).

Could I ask which technique is used on the various iDevices, especially the older ones?

Quote from: ampos on 2010-Oct-28
But the question is why is slower the things that should be faster...  :S

Indeed - or to rephrase "can GLBasic use the best speed techniquesfor the commonest functions please".

Quote from: Kitty Hello on 2010-Oct-28
But when you swap the buffers, the new "back" has the contents of the old frame drawn. Thus, I had to glClear(GL_COLOR_BUFFER) it.

So the BackBuffer would not contain the most recent screen image, but the frame before it? If this is consistent, and you can find a way to document it such that App authors can grok it easily enough, this still could be more useful left intact - saving some overhead in reproducing the screen contents to that point - in some cases, rather than always wiping it. A ClearScreen -1 would leave us with two new choices:

1. Paint the whole screen from scratch -as we might need to do even with the screen being cleared.
2. Rebuild the screen changes for the last frame then add the next frame's changes.

For certain types of App either of these MIGHT be a benefit over the current scenario - though I am a little concerned that in some situations glClear(GL_COLOR_BUFFER) might be so efficiently performed by a seperate GPU that it will be hard to see any improvement in speed for many apps :(

It would still be "nice" if the Backimage copy were at least as fast as using a Sprite to achieve the same ends, unless there's a specific reason that it is slower?
#28
Quote from: ampos on 2010-Oct-28
As on old Amiga double buffer works, was that way: you have 2 memory zones or screens. The displayed one was a pointer. Then you were writing in the other memory/zone. When you finished painting just told the system to change the pointervto the other screen and the new gfx operations were performed on the new hidden one.

Yup-and other old computers that predate the Amiga, too. The thing is, if it's pointers that are changed and not memory contents that are copied, then Clearscreen -1 might not save as much time as you may be hoping for - because there is no "old copy" of the screen to leave in place. Optimising "ClearScreen" and "UseAsBMP" to be faster might be a better option, if possible. Although ClearScreen -1 should always save SOME time if one is going to redraw the entire screen each frame (as in from a sprite or "Usescreen", for example).
#29
I'm not sure about that definition of useless - I mean, after all, a program which lets you view a 3D model of an iPhone from any direction has got to be a pretty useless waste of time (if a little fun to write) but, if the data (3d model and texture) is taken into account it is hardly likely to be the smallest entrant to such a competition.
#30
So, reading and re-reading the help file to try and deduce what's happening brings me down to a third iteration of my interpretation of the SHOWSCREEN command, as attached. This leads to three basic questions which I think fundamentally affect whether Gernot can significantly improve speed of screen updates for us across all platforms:

1) What does the "Swap BackBuffer and FrontBuffer" process/stage actually DO? Does it copy the BackBuffer to the FrontBuffer, or something else?

2) Can the "Copy BackImage over BackBuffer" process be optimised so that it does this in the FASTEST possible way, matching or beating similar processes that currently outpace using the BackImage?

3) If the current "Swap BackBuffer and FrontBuffer" process copies screen data in the same kind of way that the current "Copy BackImage over BackBuffer" process does, can it likewise benefit from some optimisation to improve the speed of every single SHOWSCREEN command?

[attachment deleted by admin]