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.


Messages - Galleon

Pages: [1] 2
1
QB64 Discussion / Re: _MAPTRIANGLE 3D ----> 2D ?
« on: March 01, 2022, 06:35:27 am »
I believe this is the C code used to setup the Open GL 3d viewport. Someone familiar with how Open GL calculates the 2D location of a 3D point should be able to help your further regardless of whether they are familiar with QB64 or not.

qb64\internal\c\libqb\gui.cpp
---------------------------------------------------
void set_view(int32 new_mode)
---------------------------------------------------
static int32 dst_w,dst_h;
dst_w=environment__window_width;
dst_h=environment__window_height;
glViewport(0, 0, (GLsizei)dst_w, (GLsizei)dst_h);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
//note: the max FOV is 90-degrees (this maximum applies to the longest screen dimension)
float fov;
if (environment_2d__screen_scaled_width>environment_2d__screen_scaled_height){
    fov=90.0f*((float)environment__window_width/(float)environment_2d__screen_scaled_width);
    //convert fov from horizontal to vertical
    fov=fov*((float)dst_h/(float)dst_w);
    }else{
    fov=90.0f*((float)environment__window_height/(float)environment_2d__screen_scaled_height);
}
gluPerspective(fov, (GLfloat)dst_w / (GLfloat)dst_h, 0.1, 10000.0); // Set the Field of view angle (in degrees), the aspect ratio of our window, and the new and far planes 
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
---------------------------------------------------

FYI - If undefined by the underlying library (depends on implementation/platform), gluPerspective is implemented manually by QB64 code as...
------------------------------------
double pi_as_double=3.14159265358979;
        void gluPerspective(double fovy, double aspect, double zNear, double zFar)
        {
            double xmin, xmax, ymin, ymax;
            ymax = zNear * tan(fovy * pi_as_double / 360.0);
            ymin = -ymax;
            xmin = ymin * aspect;
            xmax = ymax * aspect;
            glFrustum(xmin, xmax, ymin, ymax, zNear, zFar);
           
        }
------------------------------------

2
QB64 Discussion / Re: A million dollar accountant's headache
« on: February 08, 2022, 01:05:22 am »
A workaround for _PRINTSTRING-ing a PRINT USING (no doubt others have shared similar things in the past)

Code: QB64: [Select]
  1. DIM SHARED printUsing_backBuffer AS LONG
  2. DIM SHARED printUsing_sourceBackup AS LONG
  3. DIM SHARED printUsing_destBackup AS LONG
  4.  
  5. SCREEN _NEWIMAGE(800, 600, 32)
  6.  
  8.  
  9.     first$ = "Bobby": last$ = "Smith"
  10.     boxes% = 1510: sales! = 4530
  11.     tmp$ = "Salesperson: & &  #####,.   $$#####,.##"
  12.  
  13.     COLOR _RGB(RND * 255, RND * 255, RND * 255)
  14.  
  15.     PrintUsingInit
  16.     PRINT USING tmp$; first$; last$; boxes%; sales!
  17.     _PRINTSTRING (RND * 800 - 200, RND * 600), PrintUsingResult
  18.  
  19.     _LIMIT 10
  21.  
  22. SUB PrintUsingInit
  23.     printUsing_sourceBackup = _SOURCE
  24.     printUsing_destBackup = _DEST
  25.     IF printUsing_backBuffer = 0 THEN printUsing_backBuffer = _NEWIMAGE(1000, 3, 0)
  26.     _DEST printUsing_backBuffer
  27.     _SOURCE printUsing_backBuffer
  28.     CLS , 1
  30.  
  31. FUNCTION PrintUsingResult$
  32.     DIM result AS STRING
  33.     DIM i AS LONG
  34.     FOR i = 1 TO 1000
  35.         IF SCREEN(1, i, 1) = 23 THEN EXIT FOR
  36.         result = result + CHR$(SCREEN(1, i))
  37.     NEXT
  38.     PrintUsingResult = result
  39.     _DEST printUsing_destBackup
  40.     _SOURCE printUsing_sourceBackup
  42.  

3
QB64 Discussion / Re: The QB64 Bible (Work In Progress)
« on: February 02, 2022, 10:19:12 pm »
Quote
and saw his blinking cyan 'A' and saw that it was good
Actually he just saw red...
Code: QB64: [Select]
  1. DEF SEG = &HB800
  2. POKE 0, 65
  3. POKE 1, 132

4
QB64 Discussion / Re: A New Beginning
« on: January 22, 2022, 06:29:13 am »
Watching this with interest. As always I'll be following the "prime directive" of non-interference.

5
QB64 Discussion / Re: Need a cheaper way to do clearcolor
« on: June 28, 2021, 06:34:39 am »
Quote
The thing is why did johannhowitzer notice a speed increase when clearcolor was commented out?
Exactly. As the OP is not interested in pursuing this neither am I. But I'm inclined to believe that _CLEARCOLOR may have been the proverbial "straw that broke the camel's back" in this case. Also for in-game usage I assume some sort of temporary copy of the original was made, then the operations were performed (adding coloured shading then using _CLEARCOLOR), then the temporary copy was rendered to the screen and probably that temporary image was disposed of at some point (or re-used?). I suspect that entire process is responsible somehow for the slowness. Also given the example of pixel-art provided I wonder if the re-colouring could not have been done before the up-scaling.

Here's an alternative I did code just for fun but didn't share because I'm very sure it provides no speed benefit over _CLEARCOLOR...
Code: QB64: [Select]
  1. SCREEN _NEWIMAGE(1280, 768, 32)
  2. ship = _LOADIMAGE("ship.png")
  3.  
  4.  
  5. shipmask = getMask(ship)
  6. tempShip = _COPYIMAGE(ship)
  7.  
  8.  
  9. x = 0
  10. t = TIMER - 0.01
  12.     CLS , _RGB(0, 0, 128)
  13.     f = f + 1
  14.     PRINT CLNG(f / (TIMER - t))
  15.     FOR y = 10 TO 700 STEP 20
  16.         FOR z = 10 TO 1000 STEP 40
  17.             _DEST tempShip
  18.             _DONTBLEND
  19.             _PUTIMAGE (0, 0), ship
  20.             _BLEND
  21.             LINE (0, 0)-(100, 100), _RGBA(255, 0, 0, ABS(SIN((x + y + z) / 10)) * 255), BF
  22.             _PUTIMAGE (0, 0), shipmask
  23.             _DEST 0
  24.  
  25.  
  26.  
  27.             _PUTIMAGE (x + y + z, y), tempShip
  28.         NEXT
  29.     NEXT
  30.  
  31.     _DISPLAY
  32.     _LIMIT 30
  33.     x = x + 1
  35.  
  36.  
  37. FUNCTION getMask (img)
  38.     mask = _NEWIMAGE(_WIDTH(img), _HEIGHT(img), 256)
  39.     _SOURCE img
  40.     _DEST mask
  41.     FOR y = 0 TO _HEIGHT(mask) - 1
  42.         FOR x = 0 TO _WIDTH(mask) - 1
  43.             c& = POINT(x, y)
  44.             IF _ALPHA32(c&) = 0 THEN c& = 0 ELSE c& = 1
  45.             PSET (x, y), c&
  46.         NEXT
  47.     NEXT
  48.     PALETTE 0, _RGBA(0, 0, 0, 0)
  49.     _CLEARCOLOR 1, mask
  50.     _DONTBLEND mask
  51.     _SOURCE 0
  52.     _DEST 0
  53.     getMask = mask
  55.  


6
QB64 Discussion / Re: Need a cheaper way to do clearcolor
« on: June 26, 2021, 09:33:37 am »
I find it hard to believe that _CLEARCOLOR is solely responsible for the slowness. If we could see your full code we would be able to give better suggestions.

FYI - This is the core loop of _CLEARCOLOR in C++:
------------------------------------------
for (lp=im->offset32;lp<last;lp++){
     if ((*lp&0xFFFFFF)==c) *lp=c;
}
------------------------------------------
Just trying replace _CLEARCOLOR with something faster is a dead end imo.

7
QB64 Discussion / Re: Need a cheaper way to do clearcolor
« on: June 25, 2021, 01:01:43 am »
Keep multiple images of same sprite in memory, one with red, one without
Prepare them once when your program loads, then use them whenever needed
This technique will also make the transition to hardware-based images (33) easier later

8
QB64 Discussion / Re: QB64 - decisions
« on: June 17, 2021, 08:54:00 am »
While I don't have the time or inclination to work on QB64 anymore, and while the prioritisation of features added has been... interesting, I have to say I'm super impressed with the team managing QB64. If I ever return, it would be to work on a fully browser-based version of QB64 (compiler, IDE, and programs), something that is possible thanks to recent advances in web browsers. But I have many priorities in life so there is a good chance I will be dead by the time that happens.

9
QB64 Discussion / Re: Threading
« on: May 04, 2021, 07:56:56 am »
Calling multiple QB64 subs/functions in parallel without a lot of changes to the compiler is not going to work.
Have a look at what ...\internal\temp\main.txt looks like after compiling this simple program...
Code: QB64: [Select]
  1. c = addnums(5, 6)
  2. FUNCTION addnums (a, b)
  3.     addnums = a + b
  5.  
You will see a lot of extra code and the beginning and end of a function called FUNC_ADDNUMS.
That code is working with a range of global variables and if two SUBs/FUNCTIONs were called at the same time it's going to be very bad.
If you really need that extra power, may I suggest running multiple exes at once and using TCP/IP communication between them.

That said, if you do proceed down this route, I imagine you have more chance of inventing general AI than many of the researchers in that field.

10
QB64 Discussion / Re: Terror in the MAZE v20 (and newers)
« on: April 24, 2021, 07:20:36 am »
For anyone who wants to read more on the topic of Z-buffers and semi-transparency this article covers it in more detail.
https://www.sjbaker.org/steve/omniv/alpha_sorting.html
For the code I provided in my previous full program example to MasterGy I manually sort each of the semi-transparent maze-polygons by their distance and to keep it fast I re-use the previously sorted distance array which results in 50x less sort iterations. Bubble sort is bad, but performs reasonably for "almost already sorted" content (https://www.toptal.com/developers/sorting-algorithms/nearly-sorted-initial-order#:~:text=Insertion%20sort%20is%20the%20clear,adapt%20to%20nearly%20sorted%20data.)

11
QB64 Discussion / Re: Terror in the MAZE v20 (and newers)
« on: April 24, 2021, 06:53:45 am »
Quote
I do not understand. if I make a window, I only see the maze through the window, but not the sky and the Earth.
That's right. And you will not see all of the maze only parts of the maze.

To understand why this is requires a complex explanation which you may not understand but I will try.

On a 3D surface there is something called a Z-buffer.
When you draw a triangle the distance of each pixel is stored in the Z-buffer.
When you draw another triangle it will only draw the pixels if they are closer than the first pixels.
This works fine when a pixel is completely transparent (alpha=0, it will not update the Z-buffer) or not transparent at all (alpha=255, it will update the Z-buffer).
But what if alpha=128? Should it update the Z-buffer or not update the Z-buffer? Whatever it does could be wrong.

This is why partial transparency (alpha=1...alpha=254) is hard.
But the solution is...
1. Draw all not transparent at all/completely transparent first (the earth, the stars, the monsters...)
2. Sort all surfaces which contain partial transparency from furthest to closest and draw them in that order (in my version that is why it sorts the map's triangles based on distance)













12
QB64 Discussion / Re: Terror in the MAZE v20 (and newers)
« on: April 24, 2021, 05:17:33 am »
Code: QB64: [Select]
  1. 'what shall i do here ?????
  3. PAINT (100, 100), _RGB32(255, 255, 255, 160), _RGB32(255, 0, 0)

The 4th parameter in RGB32 is alpha

Note: PAINT is a special case where _DONTBLEND is actually unrequired but this is most likely a...
Anyway for all other drawing/printing if you want to override the dest with the source color (not blend the source colour with the dest color) and the source color has an alpha component you need to to use _DONTBLEND

13
QB64 Discussion / Re: Terror in the MAZE v20 (and newers)
« on: April 23, 2021, 10:15:57 pm »
The last version I shared yesterday supports multiple mipmap levels. It is probably set to 7 by default and it may generate too many textures for your system (as in your game every wall has its own texture to begin with).

Try changing it to 3...
DIM SHARED mipmapLevels AS LONG
mipmapLevels = 3 'max=20, recommended=7 (the higher the level the slower startup will be)

14
QB64 Discussion / Re: Terror in the MAZE v20 (and newers)
« on: April 22, 2021, 11:08:44 pm »
I'm glad you like my graphical "enhancement" suggestions.
I recommend you use a tool like MinMerge to compare the source files before and after my changes because it will give a clearer idea of what I changed.
There are a lot of things that can be improved/fixed but I don't really want to do any more on this than show you the possibilities.

Here are some ideas I have...

Distance sorting triangles with partial-transparency slowness:
(i) use the previous distance sorted array as the basis of the next array (most data will be in the right order (or close to the right order) already so the sort will be very quick
or
(ii) build a binary-node tree of distances and then traverse that tree <-- recommended solution
or
(iii) as the map is a grid, and only the walls have partial transparency, process the map from furthest grid coordinates to closest grid co-ordinates

Startup slowness for mipmap generation:
(i) Pre-generate the images at different resolutions/blurry-ness and store as files (could be impossible because they contain grid co-ordinates and colours)
or
(ii) Use integer math (atm SINGLE is the default data type which I didn't realise when coding this, no doubt this slowed down the mipmap generation code) <-- recommended solution
Note: AT present all mipmaps are the same size just with different blurry-ness, ideally the lower quality ones would be lower resolution too but you need to adjust texture co-ordinates for that

Also note that along with making each mipmap more blurry the further it is, I also darkened them (only a little bit) as they are further away. This achieved a simple lighting effect which added a bit of atmosphere.

Whether you use my ideas or not doesn't bother me. Thank you for making and sharing interesting 3D games and experiences with the QB64 community.

'***Here is an updated version with some speed improvements for mipmap generation (integer math) and distance sorting (re-use previously sorted data)***

15
QB64 Discussion / Re: Terror in the MAZE v20 (and newers)
« on: April 22, 2021, 02:48:35 am »
Here it is also with the ordering of the textures so the semi-transparent windows don't block the drawing of things behind them. I used a (slow, but didn't notice the difference on my comp) bubble sort for sorting the triangles but in theory as this is grid-based you should be able to come up with a much better way of drawing them in order.
*** updated to v3 which has some fixes ***
*** I am aware that some game-logic (being hit by enemies for example) has been broken by reordering of parts of code so if you want the proper game experience best play the one MasterGy shared. Treat this more as an example of how you might use mipmaps and transparency ***

Pages: [1] 2