Cairo Power?

[-Corso->]

Niya, I'd gladly write my own pixel-lighting-Photoshop-mimicing routines for things. I'll take a look.

Reexre, not to difficult to setup this for your own tile/pixel dimensions.
Print_X & Print_Y are the Physical screen Printing Locations.
Little x & y are the Map Coords.
'----------------------------------------------
X_Tile_Width = 50
Y_Tile_Height = 25
X_Increment = 31 'reverse increment to the left per each row
Y_Increment = 11 'the drop per each increment in x
'Calculate Print_X and Y
Print_X = X_Tile_Width * x - y * X_Increment
Print_Y = y * Y_Tile_Height + x * Y_Increment
'----------------------------------------------
I actually send the entire on screen map coords once, to this routine, record their Print_X & Y in a array, and I only ever call that array from then on. So this routine above is for setup only, I never use it to display tiles in game, but one could.

You need to find the 'drop' and 'reverse' increment by physically counting the pixels on your tile to where new tiles need to line up. I'm using unorthodox angles, so I would suggest 'neater' pixel angles than mine.

PS: I'm using what's called 'Trimetric' display. If you need to search for it.

[ISAWHIM]

Why are you using "engine.Cls" in a loop this tight?

Is there a reason to erase everything, prior to drawing the entire screen again? Seems like a redundant call to do. Which then you call "map_RenderBack", to paint over the whole "clear" screen...

That is like erasing grey pencil scribbles on a page, before you paint the whole thing solid black. That's a lot of building and dumping of memory, which then has to be built back up, instead of just "refilled" with new data. Also a "clear event" triggers a redraw, and can cause flickering between frames as it tries to draw an empty scene.

Also, each function or sub call, has an added delay to it. I see a lot of individual functions it jumps to, for "drawing", which should honestly all be within one function, "renderScreenGame" or "renderScreenInventory".

You just need to isolate the parts, within that single sub/function, for clarity.

When I do time-demo testing, using a sub/function, local or in a module, will turn a 2,000,000 call "single item action", into an action that now takes up to 2x longer to do. Just because it was put into a sub/function. As opposed to running that same code directly, within a loop.

Your main "play" loop of moving, has about 12 subs, and no telling how many more subs/function within those individual calls.

Are you using GDI, where possible, when possible, when Cairo isn't actually needed for processing? There is an alphablend GDI function that is not "the most accurate, visually", but it is highly functional for non-critical things and for use with "catching-up" between screens or in fast-moving frames/objects where visual accuracy is moot.

GDI, since windows DirectX is fundamentally embedded within OS itself, for drawing everything now, will use hardware, if windows is using hardware to draw. (You can watch your GPU use rocket when calling almost every GDI function, and it's not doing that just because it's drawing a lot. Those are internal processing cycles being used.)

[ISAWHIM]

Are you giving each "moving object" it's own set of back-buffers and canvases to work with?

This goes back to the dancing santa's thing I mentioned.



Step 13/14 is placing the characters clean back-buffer (first boxes), back into the next frames "active copy", instead of filling it with the whole "clean copy", which is only used for animating the moving background.

This is all as the alternative that I commonly see, where people are sending the WHOLE SCREEN to cairo or bitblt or whatever, to be processed for each individual sprite, or effect, many times. (Instead of just sending what is needed, where it is needed, when it is needed.)

Even some of the slowest blend-modes can handle these icon-sized areas fast. At 60fps, every other frame could be a poor/fast version, and your eyes would never detect it. (bad blend mode) Red+Green = Yellow, as opposed to = Brown... also Yellow+Blue = Cyan, as opposed to = Green...

Best done with a flip-flop double back-buffer, or rolling triple-buffer setup.

[baka]

do not confuse my example with OP questions.
engine.cls is in the outer loop. so its called once. and its mostly used when a "restart" happens. so very seldom.
but, after each render to screen, the bitmap is cleared. the game is animated so its hard to tell what region is the same.
if I where to make it one sub, it would be 10.000 lines long. and hundreds of goto,, it will not work.
I dont have any issues. cpu usage is 1-3% and gpu is low-usage as well. not sure how u do things, but my game runs smoothly.
its not me that have issues.

[ISAWHIM]

My apologies, Yes, I did confuse your reply for his.

Oh there are a hand-full of fast API's that can actually determine which regions are the same, using windows RECT api functions to look for intersects, merged rects, inverted rects, if rects overlap... But all that should be easily detectable if you know what you are drawing, and where you are drawing it, those are "the active regions", whatever is underneath that thing being drawn.

The line... "After each render to screen, the bitmap is cleared"...

That is one of the things I am talking about, if clearing is not needed, it shouldn't be done. Clearing is managed by pointing the object to a null-pointer-object, most-often (one that is compatible, or just a raw nullpointer to nothingness.) That causes the memory to be "released", which means that now it has to "reserve new memory-space" (creating a blank format for the object), before you can draw the new data/image/object. As opposed to using that same-sized memory-space and just expanding and shrinking it, as needed, for the new data coming in, which replaces the old object data.

But, as you said, you don't have any issues, so that isn't a problem. The OP does seem to have issues, so I am just making sure that they don't get made worse.

When vb6 is fired-up and blasting away, the most my system gets burdened is about 13% and my GPU about 20%... But I have 18 cores/32 logical processors, 64 GB RAM, 4x video-cards with 12GB each, and several dozen TB of SSDs as my only drives. Percentages say nothing valuable anymore. If it runs smooth, and its not taxing the system, then it's not really doing much to begin with. The OP doesn't seem to be in that same luxury boat. He's hitting limits that need resolutions. Limits you don't seem to have hit, or come near. I deal with these limits in almost every project I have built, because I need to know the limits and need to find ways to get around them, making new limits that I can't get past. :P

[Niya]

But I have 18 cores/32 logical processors, 64 GB RAM, 4x video-cards with 12GB each, and several dozen TB of SSDs as my only drives.

Good lord!

Lemme guess, you're the type of guy that would keep a fully grown tiger as a pet

[ISAWHIM]

I where to make it one sub, it would be 10.000 lines long. and hundreds of goto,, it will not work.

That is exactly what it is now... You just added "delays" between calls, "gotos"... which exactly what a sub and a function is, a "goto"... Previously also named "GoSub".

Saying this...

function1
function2
function3
fucntion4

is literally the same thing as having 10,000 lines all one after the other... Unless you, at some point, jump to function1 then 3, then 1 then 2, then 4... you just chopped-up the code into "sections" and are running through each linear section, which could have just been, "function1".

10,000 lines is 10,000 lines, no matter if you chopped it up into 10x 1000 line sections, or had it as one solid set of 10,000 lines. Granted, I don't know what the rest of the code looks like, but you said that was your "main loop", so, in essence, that's it, unless you are jumping through nested functions, from within those functions, which would be as bad as a bunch of nested goto-literals. (Creating functions and subs, actually ADDS more lines of code, it doesn't reduce it that way.)

Also, for the record, "goto" is faster than a "sub" or "function". The code that runs all these programs, assembly, depends heavily on goto jumping to get around, almost everywhere, because it's faster, not because it's easy to deal with. The same applies to VB6, or any language, for that matter.

"Goto" doesn't create a return-point, doesn't reserve memory to run it, doesn't have "checks" to enter and exit it, and doesn't have checks for "provisions", like a sub and a call do. it just jumps there (moves) and begins executing as if it were linear code. It's so fast, it's almost immeasurable within a stack of 2,000,000 operations, measured in milliseconds. While a Sub or a function, will stall those operations, so much that only about 1,000,000 get completed in the same time.

It's still so powerful that it's now being found as a common-practice in .NET, and has been extended to be even faster, using the "Try" function/method. Something that I wish VB6 had done.

[ISAWHIM]

I do a lot of 3D rendering and design, and visual-AI work, as well as normal graphic-art stuff. No tigers here...

Oh, and all of this is in addition to 3D-space-mouse, cad-mouse, a 16" drawing-digitizer tablet, a 65" 4K curved screen monitor (actually a TV, because it was cheaper), various controllers and joysticks, some extra monitors for testing multi-monitor stuff, her "twin" that is more like the ugly twin with a slightly lower IQ and memory, and a few keyboards.

I think a Tiger would have been cheaper to own and sustain.

At the same time, my phone is just barely "smart", I spend more time using actual "Paper Notepads", and the actual program "Notepad". I prefer paper and pencil or ink, as opposed to digital-art for creation. I would rather spend my time outside, away from all the electronics I hate, which I am damned to continue using. I'd rather be a tiger, than own one. :P

I would write 100 lines of code, just because it is faster than a one-line function, like "Str$(x)" and "StrConv(vbUpperCase)". I am also the type of person who would write individual "bits" as bytes, into a file, to use as an array of boolean values, because VB6 uses Integer for a Boolean value, in memory. An array of 100000 x 100000 becomes severely massive and takes more time to access than a simple random file-read of an actual set of boolean (bits) of data.

[-Corso->]

Just updating the 'Planter Box' method results.

140ms per move and full refresh, no lighting. (Mode 2-'style' test)

So it's not worth looking at. But the code is so insanely short and clean (just 20 lines in the draw routine!) that it would be ideal for hundreds of characters on screen at once, & GPU lighting...

*Sigh*

ISAWHIM, do you draw stuff?

[Niya]

I do a lot of 3D rendering and design, and visual-AI work, as well as normal graphic-art stuff. No tigers here...

Oh, and all of this is in addition to 3D-space-mouse, cad-mouse, a 16" drawing-digitizer tablet, a 65" 4K curved screen monitor (actually a TV, because it was cheaper), various controllers and joysticks, some extra monitors for testing multi-monitor stuff, her "twin" that is more like the ugly twin with a slightly lower IQ and memory, and a few keyboards.

I think a Tiger would have been cheaper to own and sustain.

At the same time, my phone is just barely "smart", I spend more time using actual "Paper Notepads", and the actual program "Notepad". I prefer paper and pencil or ink, as opposed to digital-art for creation. I would rather spend my time outside, away from all the electronics I hate, which I am damned to continue using. I'd rather be a tiger, than own one. :P

I would write 100 lines of code, just because it is faster than a one-line function, like "Str$(x)" and "StrConv(vbUpperCase)". I am also the type of person who would write individual "bits" as bytes, into a file, to use as an array of boolean values, because VB6 uses Integer for a Boolean value, in memory. An array of 100000 x 100000 becomes severely massive and takes more time to access than a simple random file-read of an actual set of boolean (bits) of data.

You are a very interesting individual with some interesting toys. You'll fit right in here. Welcome to VBForums.

[Schmidt]

@Corso
Without some kind of "concrete, but reduced Demo-SampleCode" -
there will be no real help coming forward.

Is it not possible for you, to post something in this regard (uploading it as a Zip-Archive here)?

Something which comes with only "rudimentary terrain-resources" (just a handful of PNGs) which is then able:
- to show the basic principle of your game-loop
- including the trimetric tile-placement/rendering you're using
- and also shows how "trees and boulders" are placed on these tiles
- and a simple "game-character"-cursor
- able to fill-up a 1920x1080 surface
- ending up with your final "lighting"-routine (which seems to be the only "performance-eater" here)

If you do that, I'd be willing to even integrate all this into the demo shown here:
https://www.vbforums.com/showthread....arge-Game-Maps

So that you end up with basically "unlimited Map-space" and a decent render-performance.

@everyone else
As for the "performance-eater" (the "Overlay-Blend-Operator" in cairo)...

Here the cairo-devs apparently did not implement using SIMD-instructions (but in "plain C" instead),
due to the complexity of the underlying formula...
The higher complexity BlendOperators are described in the Link below - in the nice cairo-documentation!
...under section "Blend Modes" in the middle of the page):
https://www.cairographics.org/operators/

Excerpt:
The resulting alpha (aR) is:
aR = aA + aB·(1-aA)

The equation for the color components follows this form:
xR = 1/aR · [ (1-aB)·xaA + (1-aA)·xaB + aA·aB·f(xA,xB) ]

Blend mode function f(xA,xB) for CAIRO_OPERATOR_OVERLAY:

if (xB <= 0.5) 'when the destination-pixel is somewhat darker
... f(xA,xB) = 2·xA·xB
else 'when the destination-pixel is somewhat lighter
... f(xA,xB) = 1 - 2·(1 - xA)·(1 - xB)

It should be relatively easy - especially when the "lightening" using this Operator,
is performed on the entirety of the whole backbuffer-surface, shortly before the "flip to the Screen" via Srf.DrawToDC -
to instead upload this backbuffer-surface as e.g. an OpenGL-texture -
and then implementing that "mathematical Overlay-formula as shown above" via GLSL-shader-language -
then doing the "final Screen-Flip" to the target-hWnd via OpenGL-API directly from the GPU.

The concrete GLSL-implemenation for the Overlay-math as shader-routines is actually quite simple, as shown here:
https://github.com/jamieowen/glsl-bl...r/overlay.glsl
(reexre and the trick should have experience with that already and could assist here).

HTH

Olaf

[Niya]

Just to be clear about something. Looking at the GLSL Overlay function:-

vec3 blendOverlay(vec3 base, vec3 blend) {
	return vec3(blendOverlay(base.r,blend.r),blendOverlay(base.g,blend.g),blendOverlay(base.b,blend.b));
}

I assume base represents the base image and blend is other image being blended into it. So base.r is the red component of the base image's current pixel. vec3 is a 3 element vector that holds the RGB values for a pixel. Is this right?

[baka]

@ISAWHIM

not sure why u try to help, since your suggestions will not work here.
also its quite confusing that u think 10 or so calls are a bad idea when u don't have a clue what those has.

this is the "ending" (part) of the engine.rendering

hTarget.BeginDraw
hTarget.DrawBitmap cTarget.GetBitmap, ResizeRect, 1, InterPolationMode, GameRect
hTarget.EndDraw ByVal 0&, ByVal 0&
' CLS
cTarget.BeginDraw
cTarget.Clear bcolor

1 time each frame (usually 60 per second) the bitmap cTarget is rendered to screen.
this is used so, if the screen size is changed it will do that here. kind of the same as a dubbleduffering StretchBlt.
also, only here I use "interpolation", that if 1:1 it will not be used, but if resized it will affect quality.

now. cTarget is the bitmap that is cleared all the time.
why? before cTarget is used hundreds of times if not more each frame.

background is usually multi-layered (could be inside a house so it could be 1 solid layer). (its 2D, platform perspective), with animated clouds, parallax mountains, animated objects floating around etc.
this part is big on its own. so I call it separately.
next is the "platform" zone. here we have nature, houses, animated objects, tiles etc. here we don't need parallax, since they are close to the npc/monsters.

now we have monsters, npc, reactors etc. those are also animated.
after that frontlayer- that could be mist or nature that are "covering" the part, that can also be animated.

so, it could be 10 layers of stuff, covering each other, with semi-transparent areas. how the heck can I check everything? it would freeze the game with all that checking.
I mean, your suggestion is to check each part if they are redraw or not. that will be more cpu consuming than simply make a copy, that is just like a bitblt.

we use functions/subs because of readability. easier to maintain.
and those calls are "microscopic" timewise, its the content that matters and often the most time confusing is string operations, databases,heavy calculations and graphic work.
the reason I have so little cpu-usage is because I work with safearrays, with bitmap-fonts, pre-build databases, I try to avoid any heavy calculations (I have a pre-build tool)
also, I use "dual-threading". so 1 thread is for music/screenshot/wordcheck, so it will not affect speed. when I load/save database I use copymemory to create a memory-range when I save (save tons of time) etc. so u don't need to worry about optimization. I have been doing this for years. and If Im stuck I ask for help. Im sure theres more I can do, but right now Im quite happy with it, and after 5 years I think I have reacted a point its quite optimized.

[Niya]

so, it could be 10 layers of stuff, covering each other, with semi-transparent areas. how the heck can I check everything? it would freeze the game with all that checking.
I mean, your suggestion is to check each part if they are redraw or not. that will be more cpu consuming than simply make a copy, that is just like a bitblt.

Yea I second this. I really despise dirty rectangle optimization techniques for game engines. It just makes the rendering process far more complicated than it needs to be. It's ok for simple games but not for anything more sophisticated that involves layers of rendering.

Also, I typically trust standards set by industry leaders and no well known game engine I know uses dirty rectangles to optimize rendering.

[Schmidt]

Just to be clear about something. Looking at the GLSL Overlay function:-

vec3 blendOverlay(vec3 base, vec3 blend) {
    return vec3(blendOverlay(base.r,blend.r),blendOverlay(base.g,blend.g),blendOverlay(base.b,blend.b));
}

I assume base represents the base image and blend is other image being blended into it. So base.r is the red component of the base image's current pixel. vec3 is a 3 element vector that holds the RGB values for a pixel. Is this right?

Yes - the whole thing could even be a little bit simplified,
because "blend" in Corso's case represents a "single, constant color-value" (out of the "timeOfDay-spectrum-stripe" he posted) -
so there's no "pre-upload" and then "sampling" of the pixels from an entire "blend"-source-surface needed...
Only the "Destination-Surface" (the "base" backbuffer-surface) will need to be uploaded to the GPU first.

Olaf

[-Corso->]

Olaf, well, 2.7Gb of Program + data, massively micro-subbed and interconnected everywhere inside, trimming it is wishful thinking. Uploading the entire game, even massively gutted is IP, it’s unwise to do this. Integrating it to SQL would eventually be nice, but that’s a while a way yet. Pixel interrogation via BindToArray is insanely fast for map loading, which is A-OK while the Game Mechanics, Fight Systems, Build Systems, NPC Interactivity, Story Handling, Balancing and General UI and AI is worked out first.

I’m not really stuck on map-printing-presentation, it’s the Overlays, they are feral-slow. I’m precious about it because ‘they look so dam good’. I could do ungodly things with a speedy Overlay function... Ungodly things, especially in 'Hell' terrain.
I can bare the Mode 2 speed reduction, as it redraws/moves a lot of things. AND, when Mode 2 is functional, it behooves the user to move slower, to see things pass instead of a jittery blur. So it can be rendered slower, but lighting Overlays need to be cut for it to not feel unplayable.

Currently, after a lot of tinkering last night, I’ve got 35ms screens with Mode 1 and Overlay Sky Colours, with Overlay Tinted fixed and mobile Lanterns. As opposed to 8ms with just Black Nighttime and lighting

See here on the small monitor:
Nice Effect in a room at early sunset: 35ms
https://www.dropbox.com/s/9x8n4ikyan...0Tint.jpg?dl=0

General Tests: 35ms / 35ms / 8ms
https://www.dropbox.com/s/umcj0blvb4...Tests.jpg?dl=0

Presentation wise, it’s much better than the comical early version. 30ms is the maximum square-to-square move time for the user to feel like the game isn’t lagging. So if I optimize it a bit more, and make it an exe, it’ll probably get there. However, other characters will blow out that time. Movement decisions and AI will also be added to that time cost, so I’m no longer confident for the long run.

THOUGH, if I switch off the sun overlay, 8ms is the screen update time. Which is MORE than enough. 4ms during the day. Very happy with that.

Conclusion: Attractive Overlays are slow on Cairo.

The above effect is passably nice, but it can be made better with a double overlay. I’d really like to do some tricky other things with lamp lights, but am already curbing my thoughts to not even test it anymore. Ie: Colour dodge burn spots at the centre of overlay light sources with some halo effects…. *Sigh* they would look so good... Magic stuff too...

So these GLSL-shaders are hyperspeed image operators. Sign me up! I'm going to go read the site.

[-Corso->]

Also, I typically trust standards set by industry leaders and no well known game engine I know uses dirty rectangles to optimize rendering.

*Sobbing*, but that's the only way I can get any speed currently....

[Niya]

Yes - the whole thing could even be a little bit simplified,
because "blend" in Corso's case represents a "single, constant color-value" (out of the "timeOfDay-spectrum-stripe" he posted) -
so there's no "pre-upload" and then "sampling" of the pixels from an entire "blend"-source-surface needed...
Only the "Destination-Surface" (the "base" backbuffer-surface) will need to be uploaded to the GPU first.

Olaf

Ah ok. That makes sense.

One more thing, would this be an accurate BASIC representation of the formula used on each colour component?

Public Function BlendOverlay(ByVal base As Double, ByVal blend As Double) As Double
    If base < 0.5 Then
        BlendOverlay = 2 * base * blend
    Else
        BlendOverlay = 1 - (2 * (1 - base) * (1 - blend))
    End If
End Function

[-Corso->]

Baka
How many layers to you paste down?

These are mine....
Terrain
Corner Tile 1
Corner Tile 2
Corner Tile 3
Corner Tile 4
Tree Shadow
Rock Shadow
Game Object Shadow
Item Shadow
Midband Glow
Grass
Tree
Rock
Game Object
Item
Character Shadow
Character
Character Object/tree/item/object interference ATOP
Character Sunset effect
Character Night Black effect
Mobile/Fixed Lighting
Sunset Overlay
Night Black

Probably more to come too...

[Niya]

Conclusion: Attractive Overlays are slow on Cairo.

Olaf confirmed it when he said this:-

Here the cairo-devs apparently did not implement using SIMD-instructions (but in "plain C" instead),
due to the complexity of the underlying formula...

This is actually a big deal. I'm not surprised it's eating your framerates. This would be slow as hell for a game written as a plain old function.

[baka]

@-Corso->

depends on the map. all maps are different.
example of one map:

BackColor=100,211,255
back.1,7,1,1,,700
back.2,1,,1.9,,200,12
back.3,7,5,1.7,,600
back.3,7,3,1.5,-200,720
back.4,7,2,1.1,,950
back.5,15,1.5,1,-80,400
back.5,-3,1.5,1,2147,400
back.7-8-9,-12,1.5,1,0,1050,20
back.16-17-18,-3,1.2,1,770,670
back.16-17-18,-3,1.4,1,2260,690
back.22,-3,1.1,1,2670,750
back.22,-3,1.1,1,2880,635
back.22,-3,1.1,1,3090,500
back.21,-3,1.25,1,760,900
back.22,-3,1.25,1,820,730
back.23,-3,1.22,1,900,560
back.14,-3,1.25,1,1100,760
back.15,-3,1.25,1,1500,620
back.13,-3,1.25,1,1800,550
back.19,-3,1.25,1,2000,800
back.20,-3,1.25,1,1966,740
back.19,-3,1.35,1,130,729
back.20,-3,1.35,1,100,595
back.20,-3,1.35,1,-53,686
back.24-25,-3,1.03,1,142,777
back.26a,-3,1.03,1,-55,454
ani.7.0-2,2,1.03,1,184,911,12,51
ani.5.0-2e1,2,1.03,1,386,1045,15,145
ani.6.0-2e2,2,1.03,1,158,908,17,306

this is to create the background. the numbers are different modes. parallax, moving-left/right, animations etc.

map (back)
house_shop.basic.10.0-6,5,,116,3398,781,20,1
house_shop.basic.17.0-2,5,,105,3524,674,25,1
tree.9.0-9,5,,216,1240,490,15,1
tree.9.0-9,5,3,216,1490,537,15,1
tree.9.0-9,5,6,216,2052,524,15,1
center.11.0-11,5,,222,2005,680,25,1

this is the center area.

now the front:

map (front)
ani.8.0-3,11,,17,1080,100
ani.8.0-3,11,,17,1400,110
ani.8.0-3,11,,17,1820,210
ani.8.0-3,11,,17,2220,20
ani.9.0-3,11,,17,1260,20
ani.9.0-3,11,,17,1530,220
ani.9.0-3,11,,17,1710,400
ani.9.0-3,11,,17,2150,50
ani.10.0-3,11,,12,1130,60
ani.10.0-3,11,,12,1330,10
ani.10.0-3,11,,12,1730,220
ani.10.0-3,11,,12,2030,120
ani.11.0-3,11,,12,1310,20
ani.11.0-3,11,,12,1510,220
ani.11.0-3,11,,12,1810,40
ani.11.0-3,11,,12,2210,10
ani.8.0-3,11,,17,1480,620
ani.8.0-3,11,,17,1000,780
ani.8.0-3,11,,17,1720,810
ani.8.0-3,11,,17,2120,560
ani.9.0-3,11,,17,1160,520
ani.9.0-3,11,,17,1330,770
ani.9.0-3,11,,17,1910,620
ani.9.0-3,11,,17,2250,900
ani.10.0-3,11,,12,1070,560
ani.10.0-3,11,,12,1430,623
ani.10.0-3,11,,12,1830,590
ani.10.0-3,11,,12,2130,710
ani.11.0-3,11,,12,1210,680
ani.11.0-3,11,,12,1780,658
ani.11.0-3,11,,12,1910,607
ani.11.0-3,11,,12,2240,810
ani.8.0-3,11,,17,1380,900
ani.8.0-3,11,,17,1700,1000
ani.8.0-3,11,,17,1270,1100
ani.8.0-3,11,,17,1920,950
ani.9.0-3,11,,17,1510,920
ani.9.0-3,11,,17,1740,940
ani.9.0-3,11,,17,1910,1050
ani.9.0-3,11,,17,2150,1020
ani.10.0-3,11,,12,1170,920
ani.10.0-3,11,,12,1230,1000
ani.10.0-3,11,,12,1930,960
ani.10.0-3,11,,12,2050,1050
ani.11.0-3,11,,12,1420,1060
ani.11.0-3,11,,12,1602,1000
ani.11.0-3,11,,12,1570,960
ani.11.0-3,11,,12,2150,910
ani.8.0-3,11,,17,1240,331
ani.8.0-3,11,,17,1721,414
ani.8.0-3,11,,17,1986,1245
ani.8.0-3,11,,17,2211,1374
ani.9.0-3,11,,17,1060,1321
ani.9.0-3,11,,17,1690,1234
ani.9.0-3,11,,17,1862,396
ani.9.0-3,11,,17,2077,486
ani.10.0-3,11,,12,1044,1311
ani.10.0-3,11,,12,1590,1261
ani.10.0-3,11,,12,1859,1200
ani.10.0-3,11,,12,2049,484
ani.11.0-3,11,,12,1280,1298
ani.11.0-3,11,,12,1964,467
ani.11.0-3,11,,12,1599,498
ani.11.0-3,11,,12,1792,1252
ani.8.0-3,11,,17,2349,131
ani.8.0-3,11,,17,2400,214
ani.9.0-3,11,,17,2371,396
ani.9.0-3,11,,17,2399,586
ani.10.0-3,11,,12,2389,699
ani.10.0-3,11,,12,2320,1000
ani.11.0-3,11,,12,2333,1277
ani.11.0-3,11,,12,2310,70

lots of petals falling, thats why so many.
and this is excluding npc/mobs/effects/ui. as I wrote before, each "call" is doing something.
the monsters and reactors are created in-game in the editor. I don't have any .txt file for that.
so the build-in editor I can place monsters/npc in the game-area.
so, all those assets I wrote here, are used in the "game-loop"
of course only the visible on screen is rendered.
the area size of this map is 4000x1400 and the visible area is 800x600
I call it 60 times a second (my default hz) so its rendered 60 times a second.

my perspective is 2D platform like Super Mario. so I use parallax to create depth.

also, all pictures are in .png format
example, map (back) is 2140kb in size and its the "1:1" area. so its the biggest picture used.
everything else is around 5MB total, so around 7MB of pictures. this excluding npc/mobs/effects/ui.

[The trick]

https://www.vbforums.com/showthread....=1#post5597152 - there is an example with different blending modes.

[-Corso->]

https://www.vbforums.com/showthread....=1#post5597152 - there is an example with different blending modes.

@ The Trick, can your library handle a Cairo-Surface being handed to it? Ie: for fast overlay effects or even fast slapping down of Cairo-Images/layers?

I've got everything hidden in the Cario.Imagelist, which is much like the VB.Imagelist, and Cairo Surfaces which are just like VB.Image. This could solve the problem if it could.

[baka]

direct2d uses gpu memory not cpu memory. so u can't use that. but to create an imagelist is very easy.

[-Corso->]

Hi'yall, I've been re-examining the OpenGL to VB6 can of worms.

Re-found the Nehe tutorials, but, I can't figure out how to make them load without error.
I thought they were written in VB5, for at the top of the form1, it says "Version5".
See here: https://github.com/gamedev-net/nehe-...on01/Form1.frm

They don't load correctly in either VB5 or 6. But you can manually import them into VB6.
Plus the weird statements, "Begin VB.Form Form1" What the hay is that?

Any body have any ideas on making the tuts work? Are they VB5, 6 or something else?
https://github.com/gamedev-net/nehe-...tree/master/vb

[Arnoutdv]

This is the content of an actual .frm file.
You shouldn't paste the content in the IDE, but in a text editor and save the file as Form1.frm

If you open an existing *.frm file with Notepad on your computer you will see that they all start with "VERSION 5.00"
Followed by properties of the form

VERSION 5.00
Begin VB.Form Form1

[The trick]

@ The Trick, can your library handle a Cairo-Surface being handed to it? Ie: for fast overlay effects or even fast slapping down of Cairo-Images/layers?

I've got everything hidden in the Cario.Imagelist, which is much like the VB.Imagelist, and Cairo Surfaces which are just like VB.Image. This could solve the problem if it could.

You can make a GPU bitmap from bits and pass it to Direct2D to do overlay. As far as i know RAM->GPU transfering is quite fast but if you nned to transfer the bits back then it can be not so optimal.

[-Corso->]

This is the content of an actual .frm file.
You shouldn't paste the content in the IDE, but in a text editor and save the file as Form1.frm

If you open an existing *.frm file with Notepad on your computer you will see that they all start with "VERSION 5.00"
Followed by properties of the form

VERSION 5.00
Begin VB.Form Form1

Ah, got it. It's working too, and all the lessons are guiding green text everywhere. Which is great.

Time to study....

[-Corso->]

Wow, this is spectacularly bad.
When setting up a basic Cairo Surface in any of the OpenGL tutorials, it gives this error.

https://www.dropbox.com/s/rsjp3imdsv...rface.jpg?dl=0

I made a separate module.
global My_Surface as CaicCairoContext

And the Sub is where it gives the error
set My_Surface = cairo.CreateSurface(100,100,ImageSurface).CreateContext

It looks like when you have the OpenGL library active, it sh*ts all over the Cairo library. Doesn't look like they want to exist in the same space....

[jpbro]

Not sure what CaicCairoContext is? Instead of CaicCairoContext, try cCairoContext. If that doesn't work, try fulling qualifying it as RC6.cCairoContext

[-Corso->]

Not sure what CaicCairoContext is? Instead of CaicCairoContext, try cCairoContext. If that doesn't work, try fulling qualifying it as RC6.cCairoContext

Ah, that was a late night, last minute, copy paste finger slip. I tested it a number of times, even copy pasting from the Facemaker program in case I was being extra sleep deprived stupid.
Tried the Global My_Surface As RC6.cCairoContext but no luck, same error.

[jpbro]

Are you sure that your exact code is:

Global My_Surface as cCairoContext

And

Set My_Surface = Cairo.CreateSurface(100,100,ImageSurface).CreateContext

? It's a bit weird that you've name a cCairoContext variable My_Surface.

I've tried the Lesson01 OpenGL demo with the following Form1 code, and I don't see any conflicts:

' Note the ScaleMode of this form is set to pixels

Private My_Surface As RC6.cCairoContext   ' <-- This variable would be better named My_Context

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    Keys(KeyCode) = True    ' store the key down
End Sub

Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
    Keys(KeyCode) = False   ' clear the keydown
End Sub

Private Sub Form_Load()
   Set My_Surface = Cairo.CreateSurface(100, 100, ImageSurface).CreateContext
End Sub

Private Sub Form_Resize()
    ReSizeGLScene ScaleWidth, ScaleHeight   ' resize
End Sub

Private Sub Form_Unload(Cancel As Integer)
    KillGLWindow        ' stop gl
End Sub

[-Corso->]

Thanks for checking JPBro, yep, code is identically that. Mine was module based though. Double checked RC6+Widgets were referenced. Also, removed my code inserts and copied pasted yours 'as is' into the form. Same issue.

Is there some sort of extra OpenGL driver thing needed? But the examples work when I clean them up. So it doesn't appear to be that.
Are you AMD or Nvidia?

And yes, I always use My_Surface, Ground_Surface, Eye_Surface etc, as it allows me to think in Photoshop layer terms. When you are keeping track of several surfaces at once and their interactions in your head, it helps to visualize it better. Any other type of variable naming is brain poison for me, plus I automatically know what I'm sending to subs and functions, and that I don't have to remember variable names other than, oh, Clothing_Surface. It just seems perfectly natural, despite things like: Test_Surface.RenderSurfaceContent My_Surface.Surface

I'll test this on another computer that has an Nvidia card in a while.. Just have to take care of a few things. Will report back.

[-Corso->]

Windows 7 with Nvidia = A-OK
Windows 10 with AMD = No go

Not sure what the problem is, but sincerely hope it isn't the graphics card brand.

[-Corso->]

Ok, figured it out. I've got two identical RC6's and Widget's references in the Add in References section. 1 of them is obviosuly defunct. However, choosing the other also creates the same error. So doesn't matter which one you select. But, if you don't unselect the faulty one, and select the unticked RC6 ref, it chooses the one that works.
Super bizzare, but I'll see if i can unregister and remove the faulty one.

Also, is there any way of handing a Cairo Surface to OpenGL? All attemps have failed so far.

[-Corso->]

This is actually getting more interesting the longer I look.
Apparently one just has to convert PNG to RGBA raw data, and shove that into an array, to which OpenGL will pick it up via the glTexImage2D function to mount it into OpenGL.
In the lessons files, they are using bitmaps converted to RAW.

Conversion is a straight forward pixel interogation via BindToArray...


Olaf, does this below mean anything to you? There's a pre-built Cairo-GL backend for dumping surfaces directly into OpenGl. It's rather short.

https://github.com/servo/cairo/blob/...src/cairo-gl.h

[reexre]

I tried to set up the basics for such a renderizer. (Using RC6)
Maybe you can find interesting hints.
I tried putting a moving "object" that "hides" behind front ones. (but it doesn't work).
Shadows are not implemented, but I think it is enough to create them with skew and render them right after the floor.
Maybe you might be interested in Overlay, which if applied not often does not consume much time....
. maybe I should write a detailed description but I don't have time at the moment.
In any case, the code at the moment it is incomplete, nevertheless it might give some hints to you or others.

https://github.com/miorsoft/VB6-ISO-game-Test

[-Corso->]

Oh Reexre, that sounds great. I'll look at this soon. Have a massive migrane right now + sleep deprivation maxxed out. Plus, I've planned to put in the code for 'wall decorations', ie: lamp lights, paintings, etc tomorrow. I've written out the pen and paper code. I'll examine after that. Looking forward to seeing what you've discovered!

[reexre]

Oh Reexre, that sounds great. I'll look at this soon. Have a massive migrane right now + sleep deprivation maxxed out. Plus, I've planned to put in the code for 'wall decorations', ie: lamp lights, paintings, etc tomorrow. I've written out the pen and paper code. I'll examine after that. Looking forward to seeing what you've discovered!

This is just my basic attempt to make an "isometric" rendering. I don't think there is anything special about it, I say this so that you will not be disappointed by it.

Updated: 10/03/2023 19.00 (europe) V2
Updated: 23/03/2023 17.00 (europe) V3

Updated code

[-Corso->]

This is just my basic attempt to make an "isometric" rendering. I don't think there is anything special about it, I say this so that you will not be disappointed by it.[/URL]

Very smooth, even at full screen.
I can't get way with such speeds though, I've got 20 layers all needing attention, and multiple characters requiring redrawing.