Size Limits, External Runs and Text on Sprites

Just starting out? Need help? Post your questions and find answers here.
User avatar
Mijikai
Addict
Addict
Posts: 1360
Joined: Sun Sep 11, 2016 2:17 pm

Re: Size Limits, External Runs and Text on Sprites

Post by Mijikai »

Welcome @Lord Santos
1 - How many lines of source code may I have in one .PB? Hundreds of thousands? Is that possible?
Im not sure about a limit... probably depends on the memory available.
I can only speak for myslef but i usually have around 10k lines in a single source file and split it up if it gets bigger.
You can use IncludeFile & XIncludeFile to include other sources in your main source file.

2 - I'm okay with Procedures and I can also master Logic conditions and SubRoutines, but it would be easier if I had instructions like Run and Chain, that exists in QB/PDS and allows me to jump from one program to another. (i.e. I have a program for Openning of Game, another for Introduction and Rules, another to Fase 1 of game and another 5 to Fases 2,3,4,5, and 6. All I need is a way to close Program 3 and jump to program 6.
I don't need to share variables, or procedures, just need the chance to say: IF THIS, RUN FILE1.PB ELSE RUN FILE2.PB.
Is this by any way that I didn't find, possible with PureBasic in MacOS?
For games i usually have a variable that holds the state of the game.
A switch case is then used to change the flow of the execution -> load different levels, menues...

3 - How many Sprites may I use simultaneously on a PB program? Is the memory the only limit? May I have something like 10.000 sprites? I am working with a Map of 20,000 by 5,000 position and need thousands of illustrations. That's also why I'd like to jump fron one program to another.
That mainly depends on the gfx hardware and available memory.
I highly doubt however that anyone would need more than 2-5k sprites on the screen at a given time.
The main thing is to only ever draw/process what is on the screen.
You can also greatly simplify things by prerendering for example (static layers/objects)
a floor would then only need one draw call instead of one for each tile.

4- This is the last Big question for me: I'm using an OpenScreen(1680, 1050, 32, "Name of the Game") to avoid Windows, because I don't want to use windows, just a flat big LoadSprite(0,"File for Big Screen Background), with a DisplayTransparentSprite(1,"Mouse GIF (MAC is not liking PNGs)"), and then, everything is made with the use of Sprites (The reason for the 3rd question). I am trying to reduce the number of sprites by adding text over them.
Real problem is that I can not find a way to do simple Locate(x,y) and Print"Text" on screen. Is there any instruction to write text on top of a gane card sprite, or do I have to sprite characters one by one, on top of the main sprite? Do I need to create a Procedure to draw, line, by line, and plot by plot, the text I need to display?
You can use the 2D drawing functions to draw text onto a sprite or a screen.
The only thing to note here is that it is not exactly fast.
The sprite functions are fast and together with a image containing font characters and a custom drawing routine the best option.
You could combine the two methods and prerender characters with the 2D drawing commands onto a sprite. ;)

Make sure to add UsePNGImageDecoder() at start of your code to support *.png files.


PureBaisc Reference Manual:
https://www.purebasic.com/documentation/PureBasic.pdf

PureBasic Online Help/Manual (also found locally in the IDE -> Help) :
https://www.purebasic.com/documentation/index.html

Hope this helps.
Bitblazer
Enthusiast
Enthusiast
Posts: 733
Joined: Mon Apr 10, 2017 6:17 pm
Location: Germany
Contact:

Re: Size Limits, External Runs and Text on Sprites

Post by Bitblazer »

Hello and welcome to the PureBasic forum.

You can technically do what you want with PureBasic. The community is big and experienced enough and has done a lot of what you can use for your project. You could for example look into the font/text rendering done by UnionBytes with their typeface project. Combine the text rendering with an image into a graphics card and display it with sprites. Regarding the amount of possible sprites and their size, that probably depends on the target platform. Windows for example can use DirectX or OpenGL. I would think the target platform and the installed drivers and hardware do limit you at some point, but PureBasic itself does not limit you. There have been projects in the past with graphics libraries and there are currently new graphics libraries in development (RetroPixel).

If you run into any limitation with PureBasic, you will find enough people willing and able to help you to solve them. First do the available tutorials and join the PureBasic discord chat.

Check my webpage for many PureBasic resources. Click Links->PureBasic->Resources

Image
webpage - discord chat links -> purebasic GPT4All
Bitblazer
Enthusiast
Enthusiast
Posts: 733
Joined: Mon Apr 10, 2017 6:17 pm
Location: Germany
Contact:

Re: Size Limits, External Runs and Text on Sprites

Post by Bitblazer »

Lord Santos wrote: Mon Dec 05, 2022 4:44 pm There is no Open World tabletop boardgames yet...
I don't know, but when you mentioned your project idea, i instantly thought about Multiverse Designer
Lord Santos wrote: Mon Dec 05, 2022 4:44 pm I'll keep working and looking for answers. But not on Discord, I'm not a chat guy; I don't even use a social network, no Messenger, Skype, Istagram, Twitter, nothing... For me It's just a time killer, and I don't have time for those things that easily become vicious. Sorry, maybe too old for those things!
I know what you mean, but it really depends on how you use a media.

Discord allows both longterm discussions and short question / answer ones. A small discussion can save days of otherwise wasted time.
Last edited by Bitblazer on Mon Dec 05, 2022 5:11 pm, edited 2 times in total.
webpage - discord chat links -> purebasic GPT4All
Bitblazer
Enthusiast
Enthusiast
Posts: 733
Joined: Mon Apr 10, 2017 6:17 pm
Location: Germany
Contact:

Re: Size Limits, External Runs and Text on Sprites

Post by Bitblazer »

Lord Santos wrote: Mon Dec 05, 2022 5:07 pm It might be important to know that Typeface Project is a very intelligent tool, but I can not use it, because I am only using OpenScreen instructions, I am not using OpenWindow.
I don't know exactly which output device and access they use, but in the end, any 2d rendering ends up with manipulating a 2d buffer. Compared to those rendering routines, that's a minor adjustment if you need to change something from one output type to another. In worst case, you use their routines to render it into an out of display area and quietly grab that area and display it on your wanted window or screen ;) Dirty, but quickly done.

I have a feeling, the UnionBytes text routines are decently fast ;)

I remember running some speed tests on their text routines and they where pretty fast. Oh and i hope you noticed their Xenon font too. With a minor code change, it was nice to see their routines using a game art font. Look into their Typeface zip archive.
webpage - discord chat links -> purebasic GPT4All
User avatar
Mijikai
Addict
Addict
Posts: 1360
Joined: Sun Sep 11, 2016 2:17 pm

Re: Size Limits, External Runs and Text on Sprites

Post by Mijikai »

- A way to jump from one program to another.
Im not entirely sure what you mean by jumping from program to program.
You can use RundProgram() to execute another program with a parameters.
Those parameters could be used to tell the next program who started it and what it should execute next.
Bitblazer
Enthusiast
Enthusiast
Posts: 733
Joined: Mon Apr 10, 2017 6:17 pm
Location: Germany
Contact:

Re: Size Limits, External Runs and Text on Sprites

Post by Bitblazer »

You can do it like you described in purebasic, but the natural way would be to have one executable and simply have x procedures inside the executable.

A purebasic procedure would just call the other procedures with their parameters one after another. The other method is possible too, but simply creates a lot pointless overhead. You can do it many different ways in purebasic, just like in C/C++. PureBasic is a real serious programming language and not some strange proprietary collection of script commands that have all kind of limitations like others (no product names mentioned ;).

Whatever you can do in C/C++, can be done in PureBasic too. Don't let the word "Basic" fool you ;)

Just look around this forum and the current active and previous topics. For example people have written windows services, windows DLL's and linux daemons in PureBasic. The language won't limit you unless you only want to develop GPU shaders ;)
webpage - discord chat links -> purebasic GPT4All
Bitblazer
Enthusiast
Enthusiast
Posts: 733
Joined: Mon Apr 10, 2017 6:17 pm
Location: Germany
Contact:

Re: Size Limits, External Runs and Text on Sprites

Post by Bitblazer »

Bitblazer wrote: Mon Dec 05, 2022 10:05 pm You can do it like you described in purebasic...
Bitblazer wrote: Mon Dec 05, 2022 4:09 pm You can technically do what you want with PureBasic.
Bitblazer wrote: Mon Dec 05, 2022 10:05 pm Whatever you can do in C/C++, can be done in PureBasic too.
webpage - discord chat links -> purebasic GPT4All
infratec
Always Here
Always Here
Posts: 6817
Joined: Sun Sep 07, 2008 12:45 pm
Location: Germany

Re: Size Limits, External Runs and Text on Sprites

Post by infratec »

IF THIS, RUN FILE1.PB ELSE RUN FILE2.PB
You can not run a xxx.pb file.
It is not clear what you mean.

You can run executable files xxx.exe in windows xxx.app in macOS xxx in linux.
But they are standalone files and can not access the 'screen' of an other program.

So I think your example comes from an interpreter and not from a compiler.
In PB you can run procedures from other included files.
If you have only one procedure in the include file, then it is like you wrote.
If you want you can write a Macro named RUN which starts your procedure in the file.
But this is more complicated then directly call a procedure in an included file and it makes not really sense.

In general I would say: start with a small program to become familar with PB.
If you run into problems: ask

I also alays tell our newbies, that the language doesn't matter, it is the logic behind.
I can write every program in every language. It is only a question how difficult it is.
I can always write an external lib or write parts in assembler or ... to extend the possibilities.

So simply start, make tests and get familar with PB.
For this is the demo version available.
Bitblazer
Enthusiast
Enthusiast
Posts: 733
Joined: Mon Apr 10, 2017 6:17 pm
Location: Germany
Contact:

Re: Size Limits, External Runs and Text on Sprites

Post by Bitblazer »

Lord Santos wrote: Tue Dec 06, 2022 12:40 am I just can't find a Print/Write text in a graphics screen.
DrawText is one way if you use the 2D drawing commands. Another way would be to use the VectorDrawing commands and the third way would be by doing it completely yourself, for example like the Union Bytes Typeface library does. Or you could render your text into sprites and display the sprites on the screen.

Each method has advantages and problems (if you consider multimonitor support, high-DPI devices and the different individual DPI desktop settings with 4k or even 8k monitors)
webpage - discord chat links -> purebasic GPT4All
User avatar
Demivec
Addict
Addict
Posts: 4086
Joined: Mon Jul 25, 2005 3:51 pm
Location: Utah, USA

Re: Size Limits, External Runs and Text on Sprites

Post by Demivec »

Lord Santos wrote: Tue Dec 06, 2022 12:40 amAbout the instruction to write text on a screen in graphics mode, yes it's as old as GWBasic and I have it in all languages I use, including Visual Basic, Ghipmunk Basic etc. This version of Basic is not new for me. I've done a lot of smaller things with it, since version 4 and I really like it. I just can't find a Print/Write text in a graphics screen. If there isn't, okay, there is no instruction to do it directly. No problem, I'll do something about it.
Inside of a StartDrawing(ScreenOuyput()) / StopDrawing() block, use DrawText(x,y, "text") .

You really haven't provided many details about how much text would be written or the frequency of writing or how it relates to the Sprites being shown. Most text would simply be drawn/displayed after all of the underlying Sprites are drawn. It would be best to group the text rendering together so that it can be done at one time instead of being interleaved with the Sprites displayed. If the text itself is a sprite then this doesn't apply. For instance, things such as Player names can be rendered onto a sprite and shown over and over without needing to do a separate text rendering step in each frame using StartDrawing() / StopDrawing().

RunProgram() will allow you to execute separate programs. There will be some complications of maintaining a screen between the switching of programs but i don't think it would be a show stopper. Some simple testing should give you an idea if this will work for you.


Your project sounds highly involved. I wish you well in your efforts to get it implemented.
Bitblazer
Enthusiast
Enthusiast
Posts: 733
Joined: Mon Apr 10, 2017 6:17 pm
Location: Germany
Contact:

Re: Size Limits, External Runs and Text on Sprites

Post by Bitblazer »

Lord Santos wrote: Tue Dec 06, 2022 11:17 am- I need to RUN from one program to another. I need to Run external programs. Procedures don't run in paralell multitasking.
That's not true. Nowadays the problem of maximising the use of a cpu, includes the task to redesign any operation into many smaller tasks that can run in parallel in threads and each uses another execution unit (or even cpu core). PureBasic supports this, look closely into the documentation about Threads

Using only a single execution unit on a cpu that has 64 of them, is sadly still common nowadays.

Threads do have a communication and synchronisation overhead, but it is neglectably small compared to the huge overhead of launching external programs. External programs also add several new problems you need to solve. Dedicated worker threads with shared memory buffers and mutex/semaphore synchronisation are a much better solution (IMHO).
Lord Santos wrote: Tue Dec 06, 2022 11:17 am - I need to CHAIN programs because I have dozens of very large programs. (Nobody expects Excel, or Word, being procedures of the Office)
You can do that, but i suggest a good look into Threads.
Lord Santos wrote: Tue Dec 06, 2022 11:17 am - I need to write on an OpenScreen(1680, 1050, 32, "Name of Game"), after Sprites, of course!
A solution based on threads with a single master Thread that handles all the actual display stuff, is what i do in such a situation. One thread handles the display while X threads just add display commands into a huge queue. The main thread processes the queue of pending display operations and does the actual displaying.

I assume you plan on using only one physical output device anyway?
Lord Santos wrote: Tue Dec 06, 2022 11:17 am - I need to write programs with more then 10 or 20 thousand source lines each and use more than 1 or 2 thousand sprite's numbers at a time
Both is possible. The organisation of such a big complex project will be crucial. I suggest looking into the concept of Modules

ps: i started programming on the zx81 many decades ago, there are a several of us "oldtimers" here
webpage - discord chat links -> purebasic GPT4All
User avatar
blueb
Addict
Addict
Posts: 1041
Joined: Sat Apr 26, 2003 2:15 pm
Location: Cuernavaca, Mexico

Re: Size Limits, External Runs and Text on Sprites

Post by blueb »

Does this thread remind anyone of... :P
viewtopic.php?p=436497#p436497
- It was too lonely at the top.

System : PB 6.10 Beta 9 (x64) and Win Pro 11 (x64)
Hardware: AMD Ryzen 9 5900X w/64 gigs Ram, AMD RX 6950 XT Graphics w/16gigs Mem
User avatar
yuki
Enthusiast
Enthusiast
Posts: 101
Joined: Sat Mar 31, 2018 9:09 pm

Re: Size Limits, External Runs and Text on Sprites

Post by yuki »

Lord Santos wrote: Tue Dec 06, 2022 12:43 pm You're not thinking objectivelly: I am the creator and the programmer; I tell you what I need; you can do it or not. Don't try to redirect my program (that you don't know) to another way of doing things. I know what I want, I know what I need. I can't have procedures with 2GB size and running automatically without the intervention of the caller.
Lord Santos wrote: Mon Dec 05, 2022 10:57 pm Do you believe that there is a person on Earth, who can devellop a 20GByte EXE or APP with this compiler, or any one else? If you had enough free RAM, how long it would take to correct just a line and recompile it? And the MacOS will run a 20GB program with 8 or 16 GB RAM?
As I said, this is a Gigantic project. I have more than 60 notebooks and sketchbooks of code already written in a Generic Code Language.
Do you expect me to put it on a single program? Never thought why the MS Office is not only one EXE?
Because you can't do such things on a single file, filled with procedures.
You've mentioned in several places 2, 20, 50+ GB executables. This seems disproportionately large. If that's factoring in included media assets, consider writing these out to pack files and loading/unloading what's needed at runtime. (that way the compiler doesn't have to embed everything, and you can simplify authoring/updating of assets themselves)

Max (real) opcode size is 15 bytes for x86-64. Assuming each PB line translates to 100 such opcodes (it won't but this gives allowance for overhead + some data), you're talking ~1.3 million LOC to reach 2GB. That's a tremendous amount of code.

As far as why the MS Office suite isn't merely a single executable...
  • MS Office consists of several different products, purchasable separately or bundled. Splitting the executables makes this feasible.
  • Program code/data eats memory. (e.g., why load PowerPoint, Excel, etc. and all their components when only interested in Word?)
  • Different teams manage development of different products. Having a single executable/codebase would make for a more fragile development process. (e.g., bug in one product leads to blockers/bugs on another product)
  • We can share common code across products using DLLs or similar.
For the typical (in terms of frequency of occurrence, not complexity) game though, it's safe to say that the majority of gameplay logic ends up compiled into one end-result executable. Looking at the two most popular game engines:
  • Unity: all your code ends up in a giant GameAssembly.dll, with Unity's own logic in UnityPlayer.dll
  • Unreal: all your code ends up in a giant Game/Binaries/Platform/Game.exe, with plugins/DLLs landing in Engine/Binaries.
Point is: AAA games don't have a problem doing "such things on a single file, filled with procedures."

Please consider using procedures for containing logic, threading for parallelism, and modules to divide your code in a clean manner.

If you need to share procedures between multiple applications, see DLLs.

PureBasic is tremendously powerful and a joy to work in. I've no doubt you can accomplish what you want with it. That said, you'll have a nicer time going about it if you embrace a conventional approach.
User avatar
yuki
Enthusiast
Enthusiast
Posts: 101
Joined: Sat Mar 31, 2018 9:09 pm

Re: Size Limits, External Runs and Text on Sprites

Post by yuki »

Lord Santos wrote: Wed Dec 07, 2022 1:13 pmobjectivelly
Image

I've read the thread, rambling and all, to completion. If there's anything at all made clear by it, it's that you hold confused/dated notions and want to stick by them to your own detriment. All while insulting those who try to help.

I'm really trying to provide constructive input here, but please, I implore you to have more faith towards those of us in the forum when we suggest different methodologies.

My point about executable sizes is that... you shouldn't be concerned with splitting game phases into separate executables. It'll only bring about more hassle. Yes, your game is unique, and yes, I'm not privy to its exact workings. However, you won't have 2GB, 20GB, or any really prohibitive amount of game logic.

I might not be a "priest" but I'm familiar enough to know that, whatever problem you're trying to solve, chaining executables with RunProgram is likely a code smell here. In the context of a game, for instance: you can't share your opened screen across executables, so either you'll have to implement a form of message passing (and a single renderer process) or you'll just deal with a janky transition between phases as one app shuts down and another opens the screen fresh.

You're convinced it has to be one way:
Lord Santos wrote: Mon Dec 05, 2022 1:33 pm 2 - I'm okay with Procedures and I can also master Logic conditions and SubRoutines, but it would be easier if I had instructions like Run and Chain, that exists in QB/PDS and allows me to jump from one program to another. (i.e. I have a program for Openning of Game, another for Introduction and Rules, another to Fase 1 of game and another 5 to Fases 2,3,4,5, and 6. All I need is a way to close Program 3 and jump to program 6.
I don't need to share variables, or procedures, just need the chance to say: IF THIS, RUN FILE1.PB ELSE RUN FILE2.PB.
Is this by any way that I didn't find, possible with PureBasic in MacOS?
Lord Santos wrote: Tue Dec 06, 2022 12:43 pm You're not thinking objectivelly: I am the creator and the programmer; I tell you what I need; you can do it or not. Don't try to redirect my program (that you don't know) to another way of doing things. I know what I want, I know what I need. I can't have procedures with 2GB size and running automatically without the intervention of the caller.
Lord Santos wrote: Mon Dec 05, 2022 4:44 pm It would be wonderful if we could Include and Exclude lines of code on the fly, eheh.
...

But really, your problem boils down to a solution as:

Code: Select all

Define currentPhase = GamePhase::#Introduction
Repeat
  ; Run current phase to completion.
  ; Returns the next phase to run, OR #Terminate to exit.
  currentPhase = GamePhase::RunLoopForPhase(currentPhase)
Until currentPhase = GamePhase::#Terminate
You can divide different phases into their own procedures with processing loops. This way, you can share things you need to across phases. (I know you assert you have 0 sharing, but you'll almost definitely want to share helpers and data at some point. Especially keeping a single screen is handy to avoid janky transitions. Also things like images, fonts, etc. don't have to be reloaded and slow down transitions.)

As far as GamePhase::RunLoopForPhase(...), it could look something like:

Code: Select all

Procedure.i RunLoopForPhase(phaseToExecute.i)
  Select phaseToExecute
    Case GamePhase::#Introduction
      ProcedureReturn GamePhaseIntroduction::RunLoop()
    Case GamePhase::#DrawStep
      ProcedureReturn GamePhaseDrawStep::RunLoop()
  EndSelect
  ProcedureReturn GamePhase::#Terminate
EndProcedure
And of course GamePhaseIntroduction::RunLoop() can then be implemented as a standalone set of behaviours (like a whole main loop/program), while still allowing graceful connection to other phases.

When one phase passes to another, you're achieving that chaining you desire. However, in this case, it's nice and super snappy since there's no bridge between apps. If your phases can't coexist due to resource ID collisions, see #PB_Any.

This is one of the simplest ways to achieve something like this, where you've distinct scenes you want to transition between. There are quite some improvements one could make here but this intends to be a minimal legible example.

Personally I favour ECS-style but that's overcomplicating things here.
User avatar
idle
Always Here
Always Here
Posts: 5042
Joined: Fri Sep 21, 2007 5:52 am
Location: New Zealand

Re: Size Limits, External Runs and Text on Sprites

Post by idle »

Stop feeding the trolls as they say. I really thought we were dealing with a chat bot.
Locked