Hollywood forums

Is there any way to do something like:

For I tried that one, but even I set A into something else than 1, it still said "this program requires Plugin"

@REQUIRE is a preprocessor command. It does not exist during normal program execution; rather, it triggers an action by the preprocessor that takes place before the program actually starts. During normal program execution, preprocessor directives have no direct effect, so you can place them anywhere in the code. When the preprocessor executes this command, the variable A doesn't even exist yet.

and why to do it, anyway? whats the purpose behind this ?

if target is to NOT fail loading if user does NOT have it, you either include (link=true) or use @OPTIONAL instead so script not fails

if the target is to create multitarget apps , e.g. an app with jpeg support and an app with PNG support
you must use @IF (preprocessor if) to exclude loading plugin
i.e. preprocessor @IF CAN do it ..in preprocessor time..

Thanks for the "link" command. I forgot you can do that, since I was already wondering if user needs to have the hwp, but with link it comes part of exe. This should solve the problem.

Although, depends how RebelSDL works.

For point is, it mentions that when using RebelSDL, drawing circles might become slower, which could be making difference in this case.

It also mentions in instructions that just @REQUIRE RebelSDL and it will basically be working, although it still mentions having to use Hardware doublebuffer and Hardware brushes.

So point here is that in case someone doesnt want to use RebelSDL, due to circles being drawn slower, then is it possible to have it on/off.

As in, if I use @REQUIRE rebelSDL, will drawing commands then automatically go through RebelSDL in way of using the slower Circle, or will it only use those slower/faster drawing methods, if I first turn Hardware DoubleBuffer on?

As in, if I @REQUIRE RebelSDL and then never use Hardware doublebuffer nor brushes, will it then work just like RebelSDL wasnt @required in the first place?

Or will it already @REQUIRE wrap the Circle command and Cirlce command become slower, regardless if I use Hardware DoubleBuffer and brushes or not.

yes as i recall, plugins like rebelsdl , take over , fully replace graphics layer with their own

so RebelSDL / Rapagui etc can NOT be "optional"

Okay, then in that case it could be good that @REQUIRE would be optional, unless there would be some other way to turn them on/off, since it is a possibility that circles could be the main slow down on my game (I dont think it really is, but without testing I cant be sure), and therefore there could be a situation where with better graphics card RebelSDLs benefits overcome the circle problem greatly, but with lousier graphics card it might not.

I mean, I assume that if you dont have a graphics card, then circle slowdown wrapping doesnt happen, or does it?

But does the circle slowdown happen, unless Hardware doublebuffer is used first?

as in, would Hardware DoubleBuffer actually work as On/Off button for RebelSDL circle slowdown?

Bugala wrote: ↑Tue Jul 28, 2026 3:27 pm So point here is that in case someone doesnt want to use RebelSDL, due to circles being drawn slower, then is it possible to have it on/off.

This is not possible at runtime because plugins like RebelSDL or RapaGUI replace core constituents like the event loop and window handler. It's not possible to switch these things at runtime. So if you want to allow the user to choose, you have to provide separate executables.

Bugala wrote: ↑Tue Jul 28, 2026 3:27 pm As in, if I use @REQUIRE rebelSDL, will drawing commands then automatically go through RebelSDL in way of using the slower Circle, or will it only use those slower/faster drawing methods, if I first turn Hardware DoubleBuffer on?

There is no easy answer here as it depends on too many factors, e.g. the level of optimization of the SDL version used and also the graphics hardware used and also the target platform. I don't think on modern systems like Windows & macOS software drawing mode is much slower with RebelSDL because these systems have lots of horsepower. It's only on Amiga systems where things like Circle() could become noticably slower with RebelSDL but of course there is a solution here too: If you need fast Circle() performance, then draw that circle into a brush and convert that brush into a hardware brush and then draw it using DisplayBrush().

Asking for a bit of clarification for that making Circle into hardware Brush suggestion.

Do you mean that it is faster to createBrush, drawCircle into that newly created brush, and then DisplayBrush, than it is to simply Draw A Circle?

Or do you mean that if Circle is same sized every frame, then it is faster to CreateBrush, Draw a circle to that brush, and then instead of using Circle every cycle, it is faster to use that DisplayBrush every cycle?

As in, If Circles size keeps changing every cycle, then your suggestion doesnt work? But it requires that Circle stays the same for multiple cycles, to be a faster solution.

Bugala wrote: ↑Sat Aug 01, 2026 9:07 pm Asking for a bit of clarification for that making Circle into hardware Brush suggestion.

Do you mean that it is faster to createBrush, drawCircle into that newly created brush, and then DisplayBrush, than it is to simply Draw A Circle?

Or do you mean that if Circle is same sized every frame, then it is faster to CreateBrush, Draw a circle to that brush, and then instead of using Circle every cycle, it is faster to use that DisplayBrush every cycle?

As in, If Circles size keeps changing every cycle, then your suggestion doesnt work? But it requires that Circle stays the same for multiple cycles, to be a faster solution.

Yes, of course I'm talking about circles whose sizes are the same. If you want the fastest performance, you need to precompute such things. Circle() will algorithmically draw a circle which is of course slower than just copying raw pixel data around which is what DisplayBrush() does. That's why to get ultimate performance you must precompute as much as possible and try to boil everything down to just calls of DisplayBrush() because that is the fastest way to draw graphics because it's essentially just copying of raw pixels, especially if the brush is a hardware brush which means that it's in GPU memory so it can be copied in next to no time.