Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Author
Message
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 20th Nov 2016 22:44
@Mage and WickedX:
Thanks for providing the condensed code snippets; they indeed raise the issue on my end as well now. Unfortunately I'm still rather swamped with work, but now I should have something to go on once I get the time!

punkyb wrote: "Is the current setup for 9Ex now default to backdrop off? I have to do backdrop on for Text functions and backdrop off for Print to work."

That is correct, the backdrop clearing is off by default, but will be automatically switched on if you draw any sprites or 3D. This is consistent with how the original DBPro works (not the online version though for whatever reason), and was put in so that you can do simple "print"-style programs without needing additional setup such as BACKDROP OFF and SYNC OFF.
I was not aware that the TEXT command acted differently from PRINT here though, thanks for pointing that out.

@Bored of the Rings:
Thanks for the appreciation
punkyb
1
Years of Service
User Offline
Joined: 8th Sep 2016
Playing: PC and Android Games
Posted: 22nd Nov 2016 00:14 Edited at: 22nd Nov 2016 00:22
@Mage

Quote: "
When was the last time you saw a video game install a font it needed? Never I'm guessing.
https://forum.thegamecreators.com/thread/207584
"


Yes, but that does not mean that you can't load it directly which most game or game engine does because they support it. If you are not aware, but someone did a direct font load/unload routine which also works with 9Ex.

Ok I see you have different use for Cloggy's plugin so disregard that suggestion and thanks for the bitmap font creator link btw.

@Rudolpho

Quote: "That is correct, the backdrop clearing is off by default, but will be automatically switched on if you draw any sprites or 3D. This is consistent with how the original DBPro works (not the online version though for whatever reason), and was put in so that you can do simple "print"-style programs without needing additional setup such as BACKDROP OFF and SYNC OFF.
I was not aware that the TEXT command acted differently from PRINT here though, thanks for pointing that out.
"

That's good to know. I thought I have done something with my DBP installation

Check Out My DarkBasic Blog and Resource!
Mage
10
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 22nd Nov 2016 07:28
punkyb wrote: " If you are not aware, but someone did a direct font load/unload routine which also works with 9Ex."

If that works as advertised then I can appreciate that being useful.
Ortu
9
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 22nd Nov 2016 17:07
I've been using the code WickedX posted here

https://forum.thegamecreators.com/thread/214323

For automated silent font installs the first time the application is run, player never notices. Works perfectly.

Just verify licensing terms on the font first


A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
punkyb
1
Years of Service
User Offline
Joined: 8th Sep 2016
Playing: PC and Android Games
Posted: 23rd Nov 2016 03:22
Yes, that's the link and by WickedX! Thanks Ortu

Check Out My DarkBasic Blog and Resource!
CumQuaT
AGK Master
7
Years of Service
User Offline
Joined: 28th Apr 2010
Location: Brisbane, Australia
Posted: 29th Nov 2016 23:55
Oh man, I'm a little late to the game and only just discovered this...

Rudolpho, I could kiss you. Thank you so much for this. You have no idea how much trauma the function count stack overflow caused me.
Manson_NS
13
Years of Service
User Offline
Joined: 4th May 2004
Location: Denmark
Posted: 2nd Dec 2016 12:21
Hi, I am having some difficulty in choosing a working editor.
The Synergy ones all garble the code - text beeing shown differently depending on whether the text is marked or not.
Indigo works flawlessly with Free DBPro on my machine, however .9E returns this message, when compiling.

Any thoughts or recommendations?
- Just in case it makes a difference to anyone, I am running Win10, Anniversary Update

Attachments

Login to view attachments
Ortu
9
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 2nd Dec 2016 22:19 Edited at: 2nd Dec 2016 22:20
I had issues with similar messages trying to compile on 9Ex, turned out to be my .dbpro project file did not have an entry for the media root path. When I added this and set it to the directory of my .dbpro file it started working.

media root path=C:\yourProjectDir\


A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
http://games.joshkirklin.com/sulium
Kuper
9
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 5th Jan 2017 00:07 Edited at: 5th Jan 2017 00:08
found this weirdest bug:
try this simple code:
+ Code Snippet
For me I get less then 200 fps
now try this:
+ Code Snippet
now fps is over 9000!!!!!
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 6th Jan 2017 13:03
@kuper: Hm, that is indeed curious...

@Mage and WickedX: I tried to check out the most recent GitHub branch today to start on a clean slate with the compiler and try to work out what may be causing that floating point issue. It however turns out that it is present in the unaltered GitHub source as well, something I did not expect. Wasn't this working in your compiler builds WickedX? The sole thing I have to change in the code is the MakeScopeGuard function in DB3.h as this refuses to compile with certain arguments using the v100 platform toolset, however this function is never even used unless when resolving constant declarations in the DBPro source so it most certainly isn't related to the problem at hand. The assembly dump also shows signs of buffer overflows when building with this "fresh" compiler.

@CumQuaT: Thank you, glad it's of help to you! No kisses will be necessary
Mage
10
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 7th Jan 2017 06:09
Rudolpho wrote: "@Mage and WickedX: I tried to check out the most recent GitHub branch today to start on a clean slate with the compiler and try to work out what may be causing that floating point issue. It however turns out that it is present in the unaltered GitHub source as well, something I did not expect."


I don't understand how such a massive problem like this could go undiscovered so long.
It's as if literally nobody is checking these things.
Like really? Nobody tried to return a float in the year or two that source has been up?
Unbelievable.
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 7th Jan 2017 09:41
@Mage: It is likely it is something that has recently been introduced with one of the new optimizations to the compiler after it going open source. It also only happens if you call a float function from within another function; usually you would assume that if it returns what it should in one place then all places, no matter function nesting, should work the same so it isn't impossible that this would have eluded whatever test cases may have been set up. And of course, from how it looks barely anybody have used this newer version enough to see and report such bugs.
In any case, the compiler parser is a complete mess of multi-digit levels of nesting with several code duplicates in places that are even called out in comments in the code but were never refactored, so it isn't impossible that this kind of error would have snuck in somewhere. Unfortunately tracking it down includes hour-long sessions of step-through debugging, manually inspecting string wrapper classes' memory contents and a very unobvious type identifier system working with (mostly) unnamed numeric values instead of proper enums (such as 1 is an integer, 2 a float, 3 a string, 7 a 64-bit int, while 109 is a typecast operator for int32 to int64 and so on... yep, messy to understand indeed).

I've managed to fix two bugs with the assembly dump at least, so that one is displaying a bit more coherent info now (turned out two extra bytes were always written at the end of each line, potentially from out of bounds). With this it has turned out that the floating-point returning function is called, it's data just represented as "4 bytes". Then out of nowhere it is cast to a 64-bit integer, which then invokes the Print-derivative that handles such values. At this point I have little doubt that somewhere in there somebody managed to mix up a 103 for "cast to float" with a 109 for "cast to double integer". But alas, finding it has proven most elusive. Of course it could be caused by a completely unrelated parse buffer overflow or something as well.

For reference, here is the pseudo-assembly output for the incorrect conversion:
+ Code Snippet
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 7th Jan 2017 13:28
Version 1.0.0.5 is now available.
Click here to download it.

This version addresses the issue with the nested floating-point returning functions. While it appears to be working as intended now, further testing may be warranted and is welcome.
The issue turned out to be that the compiler would make an assumption that all user-defined functions always return integers in certain parsing situations. It initially does this before it has parsed return values, however in this particular case it did already know the return type but wouldn't properly associate it. It also turns out that similar issues would occur with nesting functions returning other data types such as strings or double floats.

Fixed the floating-point issues with user-defined functions.
Fixed an issue where two extra out-of-bounds bytes would be written at the end of each line of the pseudo-assembly dump written by the compiler to _Temp.dbm.
A proper compiler error will now be raised instead of the program crashing at runtime when a function attempts to returns a string literal (this was never supported as far as I'm aware and you have to use a temporary local variable for returning).


Feel free to try it out and see if everything works as intended now, and of course if there are any more bugs. I will look into the one reported by Kuper when I get the time. It is probably related to the hack I did to make it possible to "print" to the screen just once without the double buffer flickering.
Mage
10
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 10th Jan 2017 05:48 Edited at: 10th Jan 2017 05:49
I'll give this a look over in the next day or so when I have a few hours.

Thanks for the continued support.
Mage
10
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 20th Jan 2017 07:40 Edited at: 20th Jan 2017 07:48
Sorry for the late reply. I had some computer trouble that delayed me.

I tried to compile the latest build and it seems with initial tests that the returning a float problem is solved.
However a new critical problem has developed. The compiler will not compile code that returns strings.

So another fundamental show stopper bug.
Sorry for the bad news.


WickedX
8
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 20th Jan 2017 16:43 Edited at: 20th Jan 2017 16:47
To my knowledge, returning string literals has never been possible in DBPro. Try this instead.

+ Code Snippet

Sorry, haven't had much time to run tests on DBPro9Ex. But, I will as soon as I find the time. Thanks.
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 20th Jan 2017 18:14
Indeed, as WickedX said, you cannot return literal strings from a ENDFUNCTION / EXITFUNCTION statement, and as far as I recall this haven't been possible before either.
You even get a nice compile-time error about it now, as I pointed out in my last post:
Rudolpho wrote: " A proper compiler error will now be raised instead of the program crashing at runtime when a function attempts to returns a string literal (this was never supported as far as I'm aware and you have to use a temporary local variable for returning)."

This used to compile with the previous versions of DBPro9Ex, however it would cause a runtime crash, so I figured it was better this way.
Try to replace your "" with retVal$, which is initiated to an empty string at the top of the function anyway

Also wow Mage, that's one big source file. Does the Synergy editor perform well while editing that? After some developments at work where an image had to be put into a byte array the other week, I noticed that the Visual Studio 2017 RC does slow down quite significantly when you have tens of thousand of lines of code in a single file.

Also thanks for the testing and feedback guys, no worries about it taking a while
Mage
10
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 21st Jan 2017 06:02 Edited at: 21st Jan 2017 06:17
WickedX wrote: "To my knowledge, returning string literals has never been possible in DBPro. Try this instead."

No! Wrong. The code is directly ported from the latest updated CD Installed DBPro. It should work and does using DBPro. Thx for offering help.

Rudolpho wrote: "Indeed, as WickedX said, you cannot return literal strings from a ENDFUNCTION / EXITFUNCTION statement, and as far as I recall this haven't been possible before either."

I can definitively confirm that it is possible and always has been.

It's too easy, you can load up DBPro and see for yourself.
Now if you are of the opinion that this should or will not be supported then that's your call. However it is a matter of fact that this is a feature of DBPro that exists.

Rudolpho wrote: "Also wow Mage, that's one big source file. Does the Synergy editor perform well while editing that? After some developments at work where an image had to be put into a byte array the other week,"

There's just over 30,000 lines of code. Been working on this (off and on) since like 2003. Just a 3rd person shooter that I have fun with from time to time.
The thing is this is an excellent way to test the DBPro EX. I'll port the whole project and see what works and what doesn't.
If there's a performance boost I'll see it. If there isn't and there's problems I will see them.
Synergy stretches to the max. I had to swap to it years ago since the default editor was starting to lag badly when typing.

Please understand though you 2 are probably telling me that a function I probably wrote 7 years ago and have been using, relying on working correctly, instead never worked and perhaps crashes to desktop.
I have found bugs before and been like "how did this go years without being found, this should have never worked". However that type of thing is super rare, usually the program train wrecks and I am forced to correct them.

+ Code Snippet
Thanks for your continued support.
Ortu
9
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 21st Jan 2017 06:33 Edited at: 21st Jan 2017 06:34
Mage appears to be correct. This is vanilla U77:

http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.

Attachments

Login to view attachments
WickedX
8
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 21st Jan 2017 16:19
Since my beginning using DBPro, I have read posts concerning issues with returning string literals. But, it appears you are correct. However, for me this code consistently runs fine once and then crashes on exit then runs fine and then crashes on exit. After changing the string, now it crashes on exit every time.

+ Code Snippet
CSL
8
Years of Service
User Offline
Joined: 22nd Mar 2009
Location: USA
Posted: 21st Jan 2017 16:49
Rudolpho, first off thank you for working on this new version of DBPro.

I wanted to start with one tiny observation about the version number. It displays 1.0.0.4 on the Help menu although the rar file shows 1.0.0.5. So I'm not sure what I really got installed.

Prior to installing 9Ex I had a working version of DBPro's latest version with several plugins (Matrix, Cloggy's, Sparkys Collision). The first program I tried to compile received a compile error that has stumped me.
"Parameter for 'SPRITE' do not match 'Sprite Number, XPos, YPos, Image Number' at line 1765."
Line 1765 has the following code:
+ Code Snippet
Could you or someone in this forum point me in the right direction on what could be causing this? Has there been something added to the compiler that we should be aware of and would need to change in our code?
I looked through the forums but have not seen anything helpful. Thanks again!
CSL
sladeiw
8
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 21st Jan 2017 21:14
The string literals problem appeared with Windows 7 (possibly Vista). On XP it was fine to return string literals from functions.
Ortu
9
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 21st Jan 2017 22:39
My test above was run on windows 10
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Mage
10
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 22nd Jan 2017 06:30 Edited at: 22nd Jan 2017 06:41
I looked into this further and there is a problem:

1.
I made an example which showed returning an empty string "" works and does not crash the program.
It turns out that while you can in some ways get away with doing this, in some cases you cannot. It seems when doing this it can make the DB Pro system unstable and in some cases it can lead to a crash. It seems to be unreliable and not very predictable.

I found weird behavior like doing it once per sync was ok, but twice crashed the program, etc.
I was able to call TestFunc() and have it return an empty String repeatedly. But when I changed it to Print the result, or store the result in a variable the example began to crash.
Oddly the very same program will run fine some times, and will fail other times as if to suggest the random placement in memory it is loaded into each time matters or some other unseen factor.

I suspect the compiler is introducing errors which if lined up too much in one place in the compiled code or are themselves too big, cause a crash. However if small enough seem to not make an impact.


2.
While returning an empty string was unreliably stable, returning a longer string was not. Crash.
Odds of crash might increase as the string length increases.


3.
How is it that I can spend years using this and not experience a problem?
Two reasons:

A. This seems to be a very unreliable thing in DBPro and depending on how the program is laid out and other details it might only crash 1 in 10 attempts.
B. I only use this functionality in the screenshot provided. Nowhere else. It's only used to catch an error in a configuration file the program loads. The program has probably never encountered the error in question since the configuration file is written correctly each time. So I never triggered the code.


Conclusion:
Everyone seems to be right.
Mage
10
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 22nd Jan 2017 06:59
Rudolpho wrote: "Try to replace your "" with retVal$, which is initiated to an empty string at the top of the function anyway "


Something is still wrong here.

WickedX
8
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 22nd Jan 2017 07:34 Edited at: 22nd Jan 2017 07:37
The only system I have that will run 9Ex is a notebook/tablet with only a 32g drive. I had to delete 9Ex to evaluate some imaging and stacking aplications for astrophotography. After reinstalling 9Ex I'm getting a include file error so I am unable to test until I can figure this out. By default 9Ex will compile the file and not the changes made in the editor. If you havn't already, try saving the file after making the changes then compile.
Mage
10
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 22nd Jan 2017 08:21 Edited at: 22nd Jan 2017 08:26
WickedX wrote: " By default 9Ex will compile the file and not the changes made in the editor. If you havn't already, try saving the file after making the changes then compile."

No effect. There is an bug, DBPro 9Ex will not let ExitFunction command return a string at all. EndFunction seemingly unaffected.


I had to delete D3D_TEXT commands used by Cloggy's D3D Func Plugin otherwise I get this error:


So I loaded things up. There's a ton of problems all over and it's going to take a few days to identify the issues.
Several initial points:
- Frame Rate appears to be roughly 5 or 6 times higher. (Hard to judge due to missing media)
- AI Characters don't seem to be loading. But the game is gracefully handling the problem.
- The scene culling system is screwed, many game world objects are not visible.
- Some of the menu delays are not working causing fast scrolling.
- Some of the animations are not working, Player's head animates super fast, doors are frozen and don't animate.
- The trigger inputs on the gamepad are being handled slightly differently. (SEPARATE AXIS so they don't cancel each other out!!!)
- Some of the level loading might be slower. More investigation required. Might be matrix related, just a guess.
- Float returning bug appears gone. Character can now move and turn at variable speeds again with thumbsticks.

Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 22nd Jan 2017 10:53
Wow, that's a lot of feedback in a short timespan

Here's my take on the issues with string literals being returned from functions:
Literal strings are stored and referenced directly in the executable generated by the compiler. This is not a problem for calling functions or initiating dynamic strings with; it's just a pointer to whatever area the string resides in. However, when used to return from a function, it appears the DBPro runtime assumes that this is a "DBPro string". These are stored in a matrix held in dynamic memory and are what are used whenever you declare and use string variables / arrays. This system is used so that the runtime can overwrite or reallocate strings as necessary when their stored text changes. All remaining such string memory is released when the application exits. Herein lies the issue; the DBPro runtime will attempt to free the non-dynamic memory holding these return strings at shutdown. Memory allocation / deallocation functions are fickle and this may occasionally not cause any visible issues, but most of the time it will cause an access violation crash. For some reason the string "update" (reallocation) routine can get called if a function returning a string is repeatedly called as well. This probably happens because the string is considered to go out of scope when the function returns, however it doesn't always happen, which is strange. May be there is some lazy deletion scheme at work, or the runtime correctly determines that the string is not in dynamic memory sometimes, but not always.
Furthermore, DBPro uses a 2D matrix for storing strings; essentially you have an offset into a string table, which contains a pointer to the actual string data. As an empty string is represented in memory simply as a zero byte, the likelihood of "success" with an empty literal string is higher as a pointer to it, which doesn't point to another pointer to the string but to the string data itself directly, as it will be interpreted as a null pointer and ignored. This only happens if the adjacent three bytes also are 0, so it isn't guaranteed to work, but as padding is usually employed it is somewhat likely.

WickedX wrote: "Since my beginning using DBPro, I have read posts concerning issues with returning string literals."

sladeiw wrote: "The string literals problem appeared with Windows 7 (possibly Vista). On XP it was fine to return string literals from functions."

This is what I remember as well. I don't recall it working on XP, but it has been many years since I used that so it is definitely possible it did. It would at first glance seem more likely that an update from the post-XP era is what broke it, however XP may have been more lenient with its memory allocation functions as well.

@Ortu: Does that program crash for you when you close it? If not, what happens with a longer string (17+ characters)?

Mage wrote: "Conclusion:
Everyone seems to be right.
"

Isn't that awesome when it happens?

Mage wrote: "There is an bug, DBPro 9Ex will not let ExitFunction command return a string at all. EndFunction seemingly unaffected."

This is correct, my exit-function check accidentally declines both literal and "normal" strings. I will put up a fix for this as soon as I'm able to, hopefully later tonight.

WickedX wrote: "By default 9Ex will compile the file and not the changes made in the editor. If you havn't already, try saving the file after making the changes then compile."

This is controlled by the following settings in the Compiler\setup.ini file:
Quote: "[PRECOMPILER]
UseIDESourceDump=Yes/No"

If that is set to "Yes", the source dump of the IDE will be used. This has the drawback that correct line numbers may not be displayed in error messages for multi-file projects, but it doesn't require saving all source files on compilation.
If it is not specified in there it will default to "No", in which case files must be saved, as WickedX said.
This INI-file is not included when you download DBPro9Ex so as to not overwrite whatever personal settings you may have in there since earlier.

@CSL: Thank you, I'm glad you appreciate it
CSL wrote: "I wanted to start with one tiny observation about the version number. It displays 1.0.0.4 on the Help menu although the rar file shows 1.0.0.5. So I'm not sure what I really got installed."

Ah yes, this was an accident. The dialog displayed by the "About" menu in the editor resides in a separate dll file that I forgot to update for the latest release.
You can right-click on the <DBPro installation path>\Compiler\DBPCompiler.exe file and check it's "file version" attribute to verify the compiler version.

CSL wrote: "The first program I tried to compile received a compile error that has stumped me.
"Parameter for 'SPRITE' do not match 'Sprite Number, XPos, YPos, Image Number' at line 1765."
Line 1765 has the following code: «...»"

There is nothing wrong with that particular code line, which compiles and runs as expected for me.
There are a few possibilities here, the first being that the reported line is incorrect (see the section above). Have you checked a few lines up and down around line 1765 to see if the offending code may be there instead?
Another possibility again related to the above section; try to make sure you re-save all your source files and try to compile the project again, in case the UseIDESourceDump setting is set to "No" and this was an error you had but have now fixed since the last source save.

Mage wrote: "I had to delete D3D_TEXT commands used by Cloggy's D3D Func Plugin otherwise I get this error: «...»"

You get that error if there is an attempt to update a non-dynamic image. This can happen if a dll creates them itself, have you tried calling ENABLE VIRTUAL TEXTURE MANAGEMENT before whatever code causes that?
If that doesn't help there may still be cases where my workaround for this isn't fully functional, so if you could isolate some code that reproduces it that would be helpful.


Again, thanks for your interest in this project and your testing
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 22nd Jan 2017 21:31 Edited at: 22nd Jan 2017 21:32
Version 1.0.0.6 is now available.
Click here to download it.


This is mostly just a bugfix release; it fixes the issue where you cannot return a string using the EXITFUNCTION statement that was introduced in version 1.0.0.5.
It also comes with an optional precompiler that will allow you to return string literals from functions by translating code like this:
+ Code Snippet
into
+ Code Snippet

A bit of a workaround, granted, but it works and lets you use the "syntactic sugar" of returning literals in your source code.
The precompiler responsible for this is found at "Compiler\Precompiler\StringLiterals.dll" and is optional; if you don't want to use it you can remove that file.
Manson_NS
13
Years of Service
User Offline
Joined: 4th May 2004
Location: Denmark
Posted: 28th Jan 2017 23:08
When I compile, I have a message popping up after what seems to be a successful compile:
"Attach debugger and press [OK] to conitnue" - misspelling is part of the message.
Am I missing something obvious?
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 29th Jan 2017 12:48
Manson_NS wrote: "When I compile, I have a message popping up after what seems to be a successful compile:
"Attach debugger and press [OK] to conitnue" - misspelling is part of the message."

Oops, that's my fault. Apparently one of the compiler dependencies in the latest release was accidentally of a debug build. I've changed it and re-uploaded it so you can download it again, or you can just replace the compiler with the one attached to this post.
Thanks for pointing it out, I don't know how I missed it

Attachments

Login to view attachments
Manson_NS
13
Years of Service
User Offline
Joined: 4th May 2004
Location: Denmark
Posted: 30th Jan 2017 09:32 Edited at: 30th Jan 2017 11:40
Thanks a lot - I've been reinstalling Dark Basic on various PCs over the past month, with these hit'n miss events happening all over the place.

Is the Synergy Editor the editor of choice? On my system it acts weird when there's <TAB> in the code.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 4th Feb 2017 14:01 Edited at: 4th Feb 2017 14:01
Quote: "Is the Synergy Editor the editor of choice?"


Indigo is the DBPRo IDE I have used for years; I highly recommend it. Note that the latest version looks far better than the ones depicted online.

https://forum.thegamecreators.com/thread/176316
Mage
10
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 7th Feb 2017 05:49
Synergy is better than the build in editor. If Indigo is better it's not better by much from the looks of it. They seem similar. I haven't tried it with 30,000 lines of code so maybe it lags bad? Dunno
Kuper
9
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 7th Feb 2017 07:46
Synergy is the best solution imho. Indigo write weird .dbpro file. It totally different from original DBPro editor.
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 13th Feb 2017 17:49 Edited at: 13th Feb 2017 19:25
Finally returned to DBPro after a long gap and decided to improve one of my old shader demos. While debugging that I encountered an unexpected problem with the get image command - but eventually decided it was my memory playing tricks. Once I got my demo updated I looked at the forum and remembered this thread and decided it was time to give it a test.

Well, I am impressed with how stable it seems to be.

I ignored all the discussion about different versions of DBPro and simply copied all the files over my existing DBP U77RC7 installation. No significant problems so far. For example my latest demo runs perfectly without a hitch (but see caveat at end) which I hadn't expected since it's a heavy shader demo. Also, most of the original DBPro demo projects (Room Demo, etc) seem to work as well. Not sure why one or two fail - I might have "improved" the demos at some point . One of my demo games fails - I just get a blank screen. Not sure where the problem is at the moment - something to do with texture backdrop or something like that I suspect.

The main issue I have at the moment is that screen fps seems significantly slower in the demos I've tested so far. Not sure where the problem lies yet. My use of shaders perhaps? Or should I have copied the files over a different DBPro version?

Edit Just done some more testing. The following code runs at about 770 fps using the U77 compiler, but only about 150 fps using the DX9Ex compiler (version 1.006). Any reason for that difference?

+ Code Snippet


Powered by Free Banners
Kuper
9
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 13th Feb 2017 20:04
@GG
Welcome back ))
Try to ad this in the beginning:
get image 1,0,0,100,100,0
sprite 1,0,1,1
delete sprite 1
delete image 1
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 13th Feb 2017 20:37
Thanks!

That's a weird fix. The two versions now run the same. I saw your earlier post but didn't think it would apply more generally. I'll have to re-read the discussion.


Powered by Free Banners
Mage
10
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 14th Feb 2017 01:23 Edited at: 14th Feb 2017 01:24
Gandalf welcome back. I was sad you had not commented in nearly a year's time.

https://www.youtube.com/watch?v=ubUQIAn_5RY
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 14th Feb 2017 10:59 Edited at: 14th Feb 2017 11:00
Thanks for that Mage. Made my day. Not quite up to his standard though ...

I'm still doing DBP stuff and hope to get back to it properly soon. For example, some time ago I posted a demo of a shader for calculating Perlin noise style images. I've now modified that so you can, in principle at least, use it to produce endless non-repeatiing landscapes. The shader produces different heightmap images which tile together seamlessly. These heightmaps should in theory then be usable in constructing successive blocks of terrain. That terrain stage hasn't been started yet - but the shader at the core is now fully working. I was motivated to look into this by my involvement with CumQuat's Malevolence game (which is another reason I've been quiet here) - although his game uses a different method as I understand it. Here is a screenshot showing a 3x3 block of images which tile seamlessly:



Hopefully I'll be posting a cleaned up version of the code later this week.

Anyway, been doing a bit of testing of Kuper's weird fps fix and it works on all demos I've tested. Looks like Rudolpho needs to put that code at the start of every DBPro program before compiling. Looks as if the code stops something happening behind the scenes - some sort of check perhaps?


Powered by Free Banners

Attachments

Login to view attachments
Ortu
9
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 14th Feb 2017 19:17
Very cool GG
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Mage
10
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 15th Feb 2017 04:24 Edited at: 15th Feb 2017 04:41
DBPro 9Ex Bug
I am having problems reliably using Exclude Object On, Exclude Object Off.
Still testing this but there could be a bug here.


I'm loading levels in my game and the game culls objects as part of a performance optimization. Everything that is visible by the player when the level first loads is visible, can be excluded, can be made visible. These objects operate normally.
However all of the objects that are initially invisible stay that way and cannot be made visible. So most of the level appears empty until you bump into something invisible. Exclude Object Off, Show Object commands do not appear to be able to make the objects visible.


Draw Call behavior seems unaffected:

Despite the fact that these objects are invisible, there appears to be no impact to the number of draw calls. That is to say it's as if objects that are invisible but supposed to be visible still use a draw call. When these objects are supposed to be invisible/excluded they do not use a draw call.
So from a draw calls perspective everything appears to be working perfectly. From an actual what is on screen perspective there's a bunch of objects not drawing to screen.


Narrowing things down further:

1. When the player fires a gun suddenly all of the invisible objects that should be visible become visible. It seems this effect occurs when sc_rayCast() (from Sparky's collision plugin) is called but I think this is used elsewhere in the program where it does not cause the effect, which is confusing.

2. When the player pauses the game and then unpauses, suddenly all of the invisible objects that should be visible become visible. There is a pause menu but all of the code and menu can be removed with no effect. There is a Make Object Plain command that appears to be causing the pause menu to restore these invisible objects populating the video game world. If the Make Object Plain command is removed the pause menu (still completely functional) does not have this correcting effect. So basically creating a completely unrelated object suddenly restores visibility to hundreds of world objects.


I am also seeing an unrelated change in behavior with the built-in Fog effects. I have nothing to report on that just yet.


Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 17th Feb 2017 15:29 Edited at: 17th Feb 2017 15:33
Rudolpho

The only significant bug I've noticed so far is the previously noted Memory Failure bug with Advanced Terrain. However, that doesn't concern me too much because I prefer my own terrain system which works flawlessly with your DX9Ex compiler. I like the fact that the Matrix1 Plugins are now available as well.

So this is indeed looking very stable. Great work!

I tried to look at your DX11 plugin today but the demo has expired and the thread is now locked. Any chance of this coming back to life? I realise you are very busy so I'm not trying to hassle you.

Edit Do you have any plans to deal with some of the long-standing DBpro bugs in due course?
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 18th Feb 2017 10:48
@Green Gandalf
Welcome back, thank you and nice work on the tileable perlin noise example!

@Kuper & Green Gandalf
I have solved the frame rate issue (see the next post below for the latest version). It turned out that a legacy mode had been enabled when I was working on the flickering 2D (single print commands without being in a loop etc.) earlier that would cause the screen to be permanently backed up internally between frames. This mode was then reset again when a sprite was created. It now uses the "correct" approach from the start so there's no more need for the temporary sprite hack.

@Mage
You are indeed correct.
It turns out that "un-excluding" (including...?) a previously excluded object flags it for having its buffers updated, however there is also a global per-frame flag that determines when such flagged objects should be updated at all (some sort of GameGuru optimization I would assume; it is quite unnecessary to check it in all frames unless there has actually been a change). The problem is that the EXCLUDE OBJECT OFF function wouldn't set this global flag, leaving excluded objects to not be rendered until some other operation set said flag, such as the creation of a new object, vertexdata unlocking, etc. This too has been fixed in the newest version (see my next post below).

Mage wrote: "Despite the fact that these objects are invisible, there appears to be no impact to the number of draw calls. That is to say it's as if objects that are invisible but supposed to be visible still use a draw call. When these objects are supposed to be invisible/excluded they do not use a draw call."

I did not experience this during my tests so there may possibly be another issue in there. Let me know if these issues persist with the new version.
Technically the mesh rendering failed at a rather late state, and did so without reporting any failure (ie. it would look like the mesh was successfully drawn to the caller) so it makes sense that the statistics would be updated as if it was properly rendered. Still, this did not happen in my test project; I didn't think much of it until re-reading your post just now so I haven't investigated it further. But as said, let me know if things seem to be off still with the new version.

Mage wrote: "I am also seeing an unrelated change in behavior with the built-in Fog effects. I have nothing to report on that just yet."

Let me know if you find anything out.

Green Gandalf wrote: "The only significant bug I've noticed so far is the previously noted Memory Failure bug with Advanced Terrain."

Ah right, I'll have to admit that had slipped my mind hmm. I'll see if I can figure it out; not a very descriptive error though, that's for sure.

Green Gandalf wrote: "So this is indeed looking very stable. Great work!"

Thank you!


Green Gandalf wrote: "I tried to look at your DX11 plugin today but the demo has expired and the thread is now locked. Any chance of this coming back to life? I realise you are very busy so I'm not trying to hassle you."

Are you sure you're using the latest update? (There's an extended version of build 0.4.7.5 that was posted in that thread around September; it should be downloadable from the opening / second post). It isn't set to expire for many months yet and my local version runs fine still.
About the thread being locked I was under the impression that wouldn't happen to stickied threads... d'oh. I guess I'll have to ask for it to be reopened for a third time now then (if any mod reads this and feels up to the task, feel free to go ahead ).
I am still working on version 0.5 whenever I am able to (sadly time is scarce these days). I know that particular version has taken forever already, but I'm not planning to give up on it. The DX11 thread is also turning 3 years old soon, so I was kind of hoping to have some sort of update for then, but it is closing in fast so shouldn't get my hopes up too high I suppose. In any case, the Ziggurat project is still very much alive even if I don't have much to show for it at the moment

Green Gandalf wrote: "Do you have any plans to deal with some of the long-standing DBpro bugs in due course?"

Do you have any particular ones in mind?
I'll do what I can, but at some times it feels like a complete rewrite may be the proper way to proceed when it comes to DBPro. The code is quite a mess in some places and there are lots of outdated approaches and legacy behaviour that imposes various restrictions on it.
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 18th Feb 2017 10:49 Edited at: 18th Feb 2017 10:50
Version 1.0.0.7 is now available
Click here to download it.


This version fixes the issues with low frame rates when not using sprites and excluded objects remaining not rendered even after "un-excluding" them as reported by Kuper and Mage.
A build date display has also been added to the "About" dialog to better help in telling whether you have the latest version installed.

Fixed the issue where frame rates were painfully decreased when no sprites had been created in the project.
Fixed the issue where "un-excluded" objects would not be rendered again until an object (the same or completely unrelated) had its vertex data updated / added, ie. by creating a new object or updating their vertex data.

As always, please let me know if you find any further bugs or other issues. I'm aware of the Advanced Terrain failure now again after being reminded by GG.
Kuper
9
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 18th Feb 2017 13:57 Edited at: 18th Feb 2017 14:02
Well done Rudolpho!
Dark Occlusion thoughts:
Its useful thing but it doesnt work with DBPro Ex and doesnt work with not usual Proj Matrixes ( for example ortho matrix for sun shadow render )
So, I think it is possible to create something from scratch.
1) Make occlusion camera render size 1/4 of the main render
2) Render all geometry chanel R ( 1-255) So each object on the screen have color Id from 1 to 255
3) Check from 1 to 255 - if object of this color is visible in occlusion render
4) Hide all objects which not visible in occlusion render
5) Main render!
It will give good fps boost for geometry and shadow render.
What can you say about it?
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 19th Feb 2017 09:45
Thank you Kuper
While that is a good idea in theory, I'm afraid it won't work very well in practice. I'll outline some of my reasoning as per your steps below:

Kuper wrote: "1) Make occlusion camera render size 1/4 of the main render"

The size of the render target generally has a surprisingly low impact on rendering time. This can of course vary depending on the complexity of your pixel shaders, but it is not uncommon that rendering a 2048x2048 image only is about 1 - 5% slower than rendering the same scene to a 256x256 image.

Kuper wrote: "2) Render all geometry chanel R ( 1-255) So each object on the screen have color Id from 1 to 255"

This would limit you to at most 255 objects in the scene. Does that amount really make occlusion culling necessary?
You could use a R16 or R32 render target however, in which case you could fit a lot more data (ie. objects) in.

Kuper wrote: "3) Check from 1 to 255 - if object of this color is visible in occlusion render
4) Hide all objects which not visible in occlusion render"

How would you go about checking this?
Reading a texture back from the GPU to the CPU is generally very costly and would in most circumstances be as slow, if not slower, than rendering all objects unculled in the first place.
To really benefit from this you would need to have some kind of dynamic dispatch where the GPU itself can read your occlusion render map and decide whether to dispatch draw calls or not based on it. This is possible with compute shaders in DX10 / DX11, but unfortunately not so in DX9.


How I imagine occlusion culling to be implemented would be something like this:
+ Code Snippet
Kuper
9
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 19th Feb 2017 14:58
Quote: "Reading a texture back from the GPU to the CPU is generally very costly and would in most circumstances be as slow, if not slower"

Yes indeed.Main problem of such occlusion method.
Quote: "Render a simpler, bounding mesh for each object."

I think that this way was created first versions of DarkOcclusion. There is two versions:
1)DLL version
2)Occlusion system which was wrote entirely in DBPro
I will check it.But I remember that it was unstable because of such commands of "write memory" ans so on
Dll version is much better in this look.
Anyway it is stuff for another thread , I think
Thanks again.
PS
Quote: "Display modes can be changed during runtime"

Is it possible? I have crash when try to change "set display mode" in realtime
Rudolpho
11
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 19th Feb 2017 22:12
Kuper wrote: "Is it possible? I have crash when try to change "set display mode" in realtime"

Lol, you're right. I was pretty sure that was included in version 1.0.0, but apparently not. No idea how I managed to miss that. Oh well, it will be in the next release then, sorry for the misinformation
Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 19th Feb 2017 22:57
Rudolpho

Thanks for the comprehensive comments. I'll check those out carefully when I return from holiday in about 3 weeks. On the DX11 issue, I thought I had the latest update from the first post in that thread, anyway I'll check on my return.

On the Advanced Terrain Memory Failure error message, I think you get that error in DBPU77RC7 when the heightmap is missing. Could that be a clue to the source of your error? For example, an incorrect file name or something?

It's really encouraging to see you working on this.

I appreciate what you say about DBPro really needing a rewrite, however, I'll dig out my old top ten most annoying bugs and see how annoying they are before bothering you with them. Not till I return though so no hurry - and probably not even then.

Login to post a reply

Server time is: 2017-09-21 11:23:29
Your offset time is: 2017-09-21 11:23:29