• Print

Author Topic: What I'll be up to...  (Read 10073 times)

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 5208
  • QB Forever
Re: What I'll be up to...
« Reply #75 on: March 22, 2014, 02:35:13 am »
There's a lot I could say about the previous replies to this thread, let's just say that I have read them and take them all as genuine venting and not just attempts to grief others. That said, I don't believe any of it really helps QB64.

I'm pleased to announce that I have finished implementing support for hardware surfaces and the _PUTIMAGE command. None of it was straightforward to achieve, but it is the missing piece in the puzzle that QB64-GL represents. Sometime in the next 2 days I'll push changes to the repository and generate a dirty build of the changes so people can start road testing if they so desire.

Here's a summary of changes:

_COPYIMAGE(handle[,new_format_mode]) supports an option to convert images to new formats, but the only conversions it will support are no conversion (source format happens to match dest format) or format 32 to format 33. It's the primary means of converting software surfaces into hardware surfaces.
myhardwarehandle = _COPYIMAGE(mysoftwarehandle,33)

_LOADIMAGE supports mode 33 directly which avoids having to type... myhardwarehandle = _COPYIMAGE(_LOADIMAGE("myimagefile.png"),33)
myhardwarehandle = _LOADIMAGE("myimagefile.png",33)

_DISPLAYORDER can be used to tell QB64 which order to render software, hardware and custom-opengl-code in
_DISPLAYORDER[{_SCREEN|_HARDWARE|_HARDWARE1|_GLRENDER}[,{_SCREEN|_HARDWARE|_HARDWARE1|_GLRENDER}[,{_SCREEN|_HARDWARE|_HARDWARE1|_GLRENDER}[,{_SCREEN|_HARDWARE|_HARDWARE1|_GLRENDER}]]]]
* Any combination is allowed, except specifying the same content twice (which wouldn't make sense anyway)

_PUTIMAGE has a _SMOOTH option which uses linear-filtering when rendering content with stretched dimensions
_PUTIMAGE [[{STEP}](?,?)[-[{STEP}](?,?)]][,[?][,[?][,[[{STEP}](?,?)[-[{STEP}](?,?)]][,{_SMOOTH}]]]]
* _SMOOTH can be specified for software surfaces, but is ignored. If/when QB64 supports linear filtering on software surfaces it will work on those too. The primary logic behind this is to allow programs to be tested with & without the hardware surfaces without having to significantly change their code.
* The destination screen can be omitted(defaults to 0), 0(the _HARDWARE surface) or 1(the _HARDWARE1 surface). Or it can be the handle of another hardware surface.
* When rendering onto the hardware "screen" surfaces, the _BLEND state of your current software display page and its dimensions will be used. Because of this, it makes sense to think of the _HARDWARE and _HARDWARE1 surfaces as new screen pages which can sit in front or behind your display page.

These commands also support hardware handles:
_FREEIMAGE
_WIDTH
_HEIGHT
_BLEND
_DONTBLEND

_DISPLAY tells QB64 to render all of the hardware _PUTIMAGE commands. If you don't call _DISPLAY, the hardware commands will continue to be buffered until you do (or your computer runs out of memory).
* There is a significant difference between hardware and software commands. Software rendering commands are performed immediately. Hardware rendering commands are buffered (imagine a long list of _PUTIMAGE commands) and _DISPLAY tells QB64 that this list of commands is ready to be rendered.
* Hardware rendered "screen" content is not persisted between calls to _DISPLAY, so imagine that a CLS command is automatically performed before your hardware commands for each frame. However, you can create a hardware image the same size as the "screen" and render to it, then render that hardware image to the screen if you wish to persist the hardware "screen" content.

In layman's terms:
* Mode 33 images are hardware accelerated, and are created using _LOADIMAGE or _COPYIMAGE (_NEWIMAGE not supported yet, it will be later)
* The only command you can (currently) use to render hardware images is _PUTIMAGE
* _DISPLAY must be called, and a "CLS" of the hardware "screen" is performed automatically between calls to _DISPLAY

The most obvious questions are why I didn't include support for LINE, _MAPTRIANGLE, _NEWIMAGE etc in this initial release. The answer to this question is that it was not a priority. These are all planned for subsequent releases. The key part of this initial release is getting the hardware sub-system to work as it should, and anything else becomes trivial.

I have to admit to breaking Android compatibility with these changes. It's something I'll be rectifying immediately after initial debugging of this sub-system is completed. I'm not aware of anyone (except myself) having any success with the Android version thus far, so I doubt anyone will notice in the interim.

I'll let everyone know when/which "dirty" build to download here as soon as it becomes available.

It may seem strange that I'm working on hardware acceleration when there is still a wide gap between what QB64-SDL can do and QB64-GL which needs to be bridged, and there are months of quite legitimate bugs to fix. To me, it was a matter of getting the foundations of QB64-GL right. I knew the whole display pipeline needed to be reworked and I was turning a blind eye to it because of the complexity of the task which I knew would have to incorporate hardware accelerated commands and I knew this would need a completely different approach to anything that had been done previously. I look forward to working with you to fix the bugs reported last (and early this) year and bridge the QB64-SDL to GL divide over the course of this year.
« Last Edit: March 22, 2014, 02:44:32 am by Galleon »
Something old... Something new... Something borrowed... Something blue...

SMcNeill

  • Moderator
  • Hero Member
  • *****
  • Posts: 4697
Re: What I'll be up to...
« Reply #76 on: March 22, 2014, 05:05:27 am »
Exciting changes!   I'll be looking forward to giving this a test run and I'll report how it does for you after I've had a chance to kick it around some and look for any bugs and such.  I'm really looking forward to see what the performance boost to GL powered programs can be.  ;)
http://bit.ly/TextImage -- Library of QB64 code to manipulate text and images, as a BM library.

http://bit.ly/Color32 -- A set of color CONST for use in 32 bit mode, as a BI library.

Pete

  • Hero Member
  • *****
  • Posts: 6626
  • Cuz I sez so varmint!
Re: What I'll be up to...
« Reply #77 on: March 22, 2014, 08:28:56 am »
Just remember, plates are hard enough to keep spinning when they're empty. Don't burn yourself out. After all, SCREEN 0 is all you'll ever need.

Best Wishes,

Pete  :)

It's only rocket science; it's not Linux!

SMcNeill

  • Moderator
  • Hero Member
  • *****
  • Posts: 4697
Re: What I'll be up to...
« Reply #78 on: March 22, 2014, 08:44:53 am »
Quote from: Pete on March 22, 2014, 08:28:56 am
Just remember, plates are hard enough to keep spinning when they're empty. Don't burn yourself out. After all, SCREEN 0 is all you'll ever need.

Best Wishes,

Pete  :)

But just think Pete:  What can you do with hardware accelerated SCREEN 0?!    WOOOOOOOOOOOOOOT!!
http://bit.ly/TextImage -- Library of QB64 code to manipulate text and images, as a BM library.

http://bit.ly/Color32 -- A set of color CONST for use in 32 bit mode, as a BI library.

Clippy

  • Hero Member
  • *****
  • Posts: 17732
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
Re: What I'll be up to...
« Reply #79 on: March 22, 2014, 10:23:49 am »
Quote
_COPYIMAGE(handle[,new_format_mode]) supports an option to convert images to new formats, but the only conversions it will support are no conversion (source format happens to match dest format) or format 32 to format 33. It's the primary means of converting software surfaces into hardware surfaces.
myhardwarehandle = _COPYIMAGE(mysoftwarehandle,33)

Hmmm, so you can change _COPYIMAGE at the drop of a hat after YEARS of use, but you cannot fix other commands or usages?
« Last Edit: March 22, 2014, 10:42:24 am by Clippy »
QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip

Billbo

  • Hero Member
  • *****
  • Posts: 516
Re: What I'll be up to...
« Reply #80 on: March 22, 2014, 05:36:56 pm »
Galleon,

A lot of great work, and you're getting
closer to  the finish-line all the time.

Bill

Pete

  • Hero Member
  • *****
  • Posts: 6626
  • Cuz I sez so varmint!
Re: What I'll be up to...
« Reply #81 on: March 22, 2014, 07:39:22 pm »
LOL - I love you Bill, but think about what you wrote, and the nature of the industry. Just when you think you're about to cross that line, some ^%^#% moves it further away! In other words, there are no such things as finished projects, there's only the next version thereof.

Pete  ;)
It's only rocket science; it's not Linux!

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 5208
  • QB Forever
Re: What I'll be up to...
« Reply #82 on: March 22, 2014, 09:49:10 pm »
Quote
so you can change _COPYIMAGE at the drop of a hat
Not at all. The format will support all 3 forms of _COPYIMAGE, but because QB64 only supports one optional argument at present I decided I'd either A - Ideally, I'll add support for multiple optional arguments or if that plan fails B - hardcode support for _COPYIMAGE with no arguments. This will be part of phase 2 which will include _MAPTRIANGLE and _NEWIMAGE support. Well spotted, I should have mentioned that in my previous post. I've no intention to deprecate anything, let alone _COPYIMAGE with no parameters.
Something old... Something new... Something borrowed... Something blue...

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 5208
  • QB Forever
Re: What I'll be up to...
« Reply #83 on: March 23, 2014, 01:45:29 am »
It's alive!

To try the new hardware accelerated commands, download the latest Windows "dirty" build.
2014_03_23__00_59_29   qb64v0990-win.zip   qb64v0990-win.7z
(or more recent, but I actually tested this one worked with the attached game)

To kick start your exploration of hardware accelerated graphics I've attached a demo called "shoot2". It was thrown together as a brief test and doesn't really showcase the new possibilities, but it's better than starting from nothing. I don't own the sound/graphics which were shamelessly ripped from random places on the net without permission. I should at least acknowledge that the BG music was from http://www.youtube.com/watch?v=3ZMUvxeMFFE.

New commands are documented in this post:
http://www.qb64.net/forum/index.php?topic=11688.msg101301#msg101301

In theory this should work in Linux/OSX but no testing was done on those platforms yet.
« Last Edit: March 23, 2014, 02:18:02 am by Galleon »
Something old... Something new... Something borrowed... Something blue...

Clippy

  • Hero Member
  • *****
  • Posts: 17732
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
Re: What I'll be up to...
« Reply #84 on: March 23, 2014, 06:44:15 am »
SCREEN is already a reserved QB keyword. We don't need _SCREEN just like we don't need _OFF.

Please explain the difference between HARDWARE and HARDWARE1. Is there a 2 or 3?

Do we really need underscores for words only used by _DISPLAYORDER? These could be text parameters like other keywords. Plus a program could set the string command order as it goes perhaps?

Why not just use _GL instead of _GLRENDER. _DISPLAYORDER is only used to render.

_DISPLAYORDER has parenthesis?  Nevermind I gather that is an optional statement bracket

_DISPLAY just renders in any order if _DISPLAYORDER is not used first? What about software?

_DEST can now use 0 or 1 for hardware? How does that work if you have a software image too? Either could use 0.

Can _COPYIMAGE use 32 now? Why or when would it?

_PUTIMAGE is getting endless... Why wouldn't you want _SMOOTH anyhow? Couldn't this be done when required? It could know when an image is stretched...

Is _FREEIMAGE critical with hardware handles too?
« Last Edit: March 23, 2014, 09:00:10 am by Clippy »
QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip

Klangaroo

  • Sr. Member
  • ****
  • Posts: 327
  • Video Game Dad
    • ManFightDragon Indie Dev Blog
Re: What I'll be up to...
« Reply #85 on: March 23, 2014, 07:39:54 am »
Just in regards to your question about _SMOOTH (filtering), you definitely don't want to always use it. It looks awful in some game styles. (It's perfect for Black Annex, but in our other project we have it disabled due to dramatically different style)

edit: to clarify, I don't use QB64 GL, we have our own GL implementation in QB64 SDL (you probably know that).
I make video games over at Man Fight Dragon and I have Twitter so do whatever really.

Clippy

  • Hero Member
  • *****
  • Posts: 17732
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
Re: What I'll be up to...
« Reply #86 on: March 23, 2014, 08:02:35 am »
Well perhaps _SMOOTH could be a display option used in certain sections of code instead of with every _PUTIMAGE. That could make it better for all.

If you are using GL in SDL then you must be using DECLARE LIBRARY somewhere...  ;)
QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 5208
  • QB Forever
Re: What I'll be up to...
« Reply #87 on: March 23, 2014, 12:56:41 pm »
Quote
SCREEN is already a reserved QB keyword. We don't need _SCREEN just like we don't need _OFF.
SCREEN is implemented as a function, and ON, OFF and _SCREEN are implemented as syntax separators. If I don't use _SCREEN I'd have to use something else. How does _SOFTWARE sound?

Quote
Please explain the difference between HARDWARE and HARDWARE1. Is there a 2 or 3?
Just like the SCREEN has page 0(the default) and 1, hardware _PUTIMAGE supports 0 and 1 as destination surfaces. The difference is that these are both visible at once. There is no 2/3/etc.
Have a look at:
http://www.qb64.net/forum/index.php?topic=11688.msg101135#msg101135
The default on start-up is:
_DISPLAYORDER _SCREEN, _HARDWARE, _GLRENDER, _HARDWARE1

Quote
Do we really need underscores for words only used by _DISPLAYORDER? These could be text parameters like other keywords. Plus a program could set the string command order as it goes perhaps?
It's very unlikely a program would want to dynamically set these using string values. And to avoid potential typos and aid (possible in the future) intellisense this is a better solution. We need underscores because the programmer may have other variables declared with the same names. Again these are treated as syntactical separators so they could potentially be used in other SUBs/FUNCTIONs where expressions are not delimited by commas.

Quote
Why not just use _GL instead of _GLRENDER.
Because the _GLRENDER command can also be used to set the display order, but just for the GL layer, and this forms a strong connection between the 2.

Quote
_DEST can now use 0 or 1 for hardware? How does that work if you have a software image too? Either could use 0.
_SOURCE & _DEST do not support hardware surfaces, and when they do, the hardware _DEST will be specified as a second parameter.

Quote
Can _COPYIMAGE use 32 now? Why or when would it?
To convert a 256 color software surface to a 32bit color surface.

Quote
_PUTIMAGE is getting endless... Why wouldn't you want _SMOOTH anyhow? Couldn't this be done when required? It could know when an image is stretched...
_BLEND was necessary as a separate command because you could draw lines, circles, print text, etc onto software surfaces and QB64 needed some way of determining whether to use alpha during these operations on not. _SMOOTH is just used with _PUTIMAGE (and tba _MAPTRIANGLE) so it doesn't really need to be implemented as a separate command. Don't get me wrong, it could be done that way, but there are no real benefits apart from possibly making the command easier to type... but then you need to keep track of what _SMOOTH option you assigned to which surface, so for the sake of a few commands you end up having to type a whole lot more and have a slightly less efficient program.

Quote
Is _FREEIMAGE critical with hardware handles too?
Only as critical as with software handles. When your program exists my understanding is that all textures/etc in hardware are automatically freed. But if you have a program which manages different groups of textures at different times, it's advisable to use _FREEIMAGE to remove the ones not in use.
Something old... Something new... Something borrowed... Something blue...

Dark Star

  • Hero Member
  • *****
  • Posts: 842
Re: What I'll be up to...
« Reply #88 on: March 23, 2014, 01:24:55 pm »
Quote from: Galleon on March 23, 2014, 12:56:41 pm
If I don't use _SCREEN I'd have to use something else. How does _SOFTWARE sound?

For my two cents worth, _SOFTWARE is a bit more descriptive than _SCREEN and may cause less confusion.

Clippy

  • Hero Member
  • *****
  • Posts: 17732
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
Re: What I'll be up to...
« Reply #89 on: March 23, 2014, 01:34:54 pm »
I like _SOFTWARE too. Screen is too ambiguous! It also sets it apart from _HARDWARE better.

Still not sure what the difference in _HARDWARE and _HARDWARE1 is. If two hardware surfaces are done we should render them?

Quote from: Galleon
It's very unlikely a program would want to dynamically set these using string values. And to avoid potential typos and aid (possible in the future) intellisense this is a better solution. We need underscores because the programmer may have other variables declared with the same names. Again these are treated as syntactical separators so they could potentially be used in other SUBs/FUNCTIONs where expressions are not delimited by commas.

Well an auto-complete feature is a long way off and could complete any words after the _DISPLAYORDER keyword whether they had underscores or not. Adding parameters as reserved underscored words gets them involved with common QB64 keywords. I have avoided listing special parameters in the QB64 keyword list so far.  I see no reason that those special parameters need to be reserved if they are only used in special cases.

GL has added a TON of special keywords. Adding more on top may overload potential users!
« Last Edit: March 23, 2014, 01:49:24 pm by Clippy »
QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip

  • Print