The standard practical use of DISPLAY is once per frame in your main gameplay loop, so you can draw everything behind the scenes, and have the screen update all at once. For QB64 game developers, it is essential for anything above a text adventure, without it, you will see crazy flickering. But once per loop is not terribly expensive.
Regarding MEM, if I have to resort to essentially learning to code assembly for a single visual effect, that visual effect might have to get scrapped. I'm already putting off learning another programming language until the demo is done. I was hoping there was a workaround with some clever trick.
The image here shows the steps of the overlay process. The line statement covers the whole image surface d&, with color h~&, which has an alpha component. Then the clearcolor statement uses the bottom-right of that surface to mask out all of the overlay except the sprite. Without the clearcolor, the overlay will look like the middle sprite in the image - just an overlaid rectangle, which looks really ugly. When I commented out the clearcolor statement, no slowdown occurred.
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.In a scenario where you are calling it over an over as he is, it is a big drop in performance, for what ever reason?
Also, the full code is nearing 10k lines, I think...just FYI there is a limit to the size that can be compiled, You may eventually want to go back and rework some areas to condense and simplify your code. Another reason to pre-create all sprite effects or simplify them.(when your sprite sheet exceeds 64kx12k pxls then you will beat my largest, that was a lot of work 1000s of 16x16px sprites\tiles and a several background images before I learned the golden rule of Simplicity)
The functional code IS simple. A lot of the bulk of that is coming from data setting and scripting, which will eventually have to be offloaded to external files. Right now I'm pushing for demo completion, the full game is going to take quite a bit of optimization and smarter resource organization. Right now I've got a whole routine dedicated to setting all the dialogue lines, in the end that'll be a resource file too.I hear that, I usually start with 2 programs on a project, the MAIN code source and my DATA program that outputs all the data into an external file, I rarely(but sometimes do) attempt to start putting data into the MAIN code cause it quickly becomes messy, It can be a little tricky keeping both in sync but make does it make the main code cleaner.
I've been coding an engine from scratch, and building my first fully commercial-potential game from scratch at the same time... tons of learning experiences, and I'm definitely aware of some things that are unsustainable the way I started doing them, gotta wait until after the demo to address them though, or I'll keep pushing it back and never get there.
FYI - This is the core loop of _CLEARCOLOR in C++:
------------------------------------------
for (lp=im->offset32;lp<last;lp++){
if ((*lp&0xFFFFFF)==c) *lp=c;
}
------------------------------------------
I hear that, I usually start with 2 programs on a project, the MAIN code source and my DATA program that outputs all the data into an external file, I rarely(but sometimes do) attempt to start putting data into the MAIN code cause it quickly becomes messy, It can be a little tricky keeping both in sync but make does it make the main code cleaner.
@Galleon
The C++ code is very interesting. What does *lp&0xFFFFFF do?
&0xFFFFFF = 16,777,215 decimal. Is this the size of a memory block? and why is it fixed size of &0xFFFFFF?
Is variable c a color value?.
I have read that CLEARCOLOR and PUTIMAGE work together. Do they use the same &0xFFFFFF block of memory?
Oh . . . .could lp&0xFFFFFF be a variable name?, assembler directive?
I know lp stands for long pointer and * is some type of memory operator. I have no clue what the C++ code is doing.
DIM c AS _UNSIGNED LONG: c = _RGB32(r, g,b)
Used POINT function after CLEARCOLOR is the most speed problem
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.
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?).That's right, I've been using a dedicated image surface for pre-processing effects.
Also given the example of pixel-art provided I wonder if the re-colouring could not have been done before the up-scaling.The upscale was only for visibility on the forum, my game's code does not use putimage to stretch anything - except the laser, which is going to be in the sprite sheet pre-stretched soon.