Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers AppGameKit Corner / How to make something like paste image?

Author
Message
Ermesjr
User Offline
Joined: 11th Feb 2021
Location:
Posted: 12th Feb 2021 18:56
hi,

another question, how to paste images with agk?, there's a way? I don't want hundreds of sprite flipping around, just have images in memory and paste where i want, no need to collisions or whatever.

Maybe too basic i guess.

thanks, Ermes
n00bstar
17
Years of Service
User Offline
Joined: 9th Feb 2004
Location: Montreal, Canada.
Posted: 15th Feb 2021 00:29 Edited at: 15th Feb 2021 00:30
Hahaha... as I said in that other thread:

n00bstar wrote: "You'll probably run into problems with the way sprites work too, it's quite different from the old way of just drawing stuff to a buffer and flipping it..."


I ran into the same problem when I started with AGK.. and frankly I still haven't entirely gotten used to it to be honest. I think they expect you to create and delete sprites as you go. Feels weird to me too

Depending on what I'm doing, I will usually have two types of sprites:
1- The AppGameKit type... always existing as an actual object.
2- My own "sprite engine" where I turn them visible, position them, draw them on the backbuffer, and then make them invisible and move them off screen.

You'll have the same problem with Text commands. It creates an object instead of just writing something on the backbuffer. Having such objects can be very versatile in some situations, but when you're used to the old way of doing things... it's a freaking mess. Take this code snippet for example.. I have that in all my programs because keeping track of text objects is usually not something I need.



See how this creates a text object, positions it, draws it, then deletes it? This is how you're going to have to go about sprites too if you want them to be used the "classic" way.

I've got a tile-based game and I though it ridiculous to have over a thousand active sprite objects to keep track of just to draw a freaking tile map. What I do is use a single sprite with many frames of "animation" and I move, draw, change its frame, move, draw, change frame, move, draw, frame, move, draw.... etc etc. When I'm done drawing my tile map, I set the sprite to be invisible and move it off screen just to avoid weird collisions.

It's ass backward if you ask me, but you get used to it.
-----------------------------------------------------------------------------
We all got a chicken duck woman thing waiting for us
Ermesjr
User Offline
Joined: 11th Feb 2021
Location:
Posted: 16th Feb 2021 14:33
Thanks,

Ho my god, it's about changing all my old way, but WTF, i've used the same way with C64 basic (even simons basic), Amigabasic (really weird BTW), AMOS, Gbasic, DBC, DBpro, even Blitz3D,...

who's the mind behind AppGameKit???

I'see i'm the past. better to switch on ps4 and forget about coding.
n00bstar
17
Years of Service
User Offline
Joined: 9th Feb 2004
Location: Montreal, Canada.
Posted: 16th Feb 2021 14:57 Edited at: 16th Feb 2021 14:59
Psshh!

You'll get used to it. You just need to code a lot of boilerplate crap to get it up and running the way you want. I'm currently working on an oldschool tilemap-based game and I have to code my own sprite engine for it since I'm using 8x8 tiles and that means 3520 tiles on screen at any one time. There is no way in hell I'm going to deal with that many active sprites! So far I'm only using 5 sprites. Map, Mouse, UI, Characters, Items and pasting them the way you'd normally do.

You're in the past? Yes. But so am I, and I'm making it work. Gotta kick AppGameKit in the butt a bit to make it act normally. The "modern" way of working is, to me at least, super dumb and entirely unoptimized. They expect you to use huge sprites for every element. Want to open a window? Use a huge sprite instead of drawing your own window from corners, edges and a back fill. I find that stupid so I'm forcing AppGameKit to work like I want it to

Now you shut that PS4 down right meow and get back to coding.

[edit] btw.. I'm an old fart too.. you CAN adapt. Don't worry
-----------------------------------------------------------------------------
We all got a chicken duck woman thing waiting for us
Ermesjr
User Offline
Joined: 11th Feb 2021
Location:
Posted: 16th Feb 2021 16:31
@ n00bstar

ah no way to switch down ps4 when i'm on my sofa with my little dog on my knee, and my wife away from home for a while.
i agree 110 % with you, about crapping way to code something when it can be MORE EASY in a optimised way. "Modern Way", go to hell.

best whishes for your projects,

now i've to look for a good idea for a game and work for it.

cheers, Ermes
SFSW
18
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 17th Feb 2021 20:42
The key difference is persistence. I don't mean you as a coder, but rather the elements you want to draw remaining persistent rather than being cleared every cycle. That's really the most significant difference. And it's not too difficult to change things to be managed under such an approach. I'll share what I do with text and sprites with some code as examples. For 'paste image', I created this function:



Now this is designed to accommodate a custom 2048X2048 render image target I use for all text and image graphics. All scaling and positioning is calibrated to set the sprite size to match the image size and place it at a specific location based on that resolution. So you'll need to modify it if you want to draw directly on a screen, with or without a virtual resolution, etc. This is just to illustrate managing multiple sprites in a 'paste image' type format. The function checks to see if the sprite already exists and if it doesn't, it creates it just like 'Paste Image' would create an paste-able image in DBPro. If it already exists, then it just places it and shows it to behave the same way. Then after it's done rendering, there's a small 'for i' loop that hides it after drawing (after Render2D/Sync/Swap). Technically, you never have to delete it at this point and can just keep it in reserve for redrawing or you can delete it to redraw it with a different image.

For text, I do something similar. I create text indexes on demand as needed, then hide them when not needed. And if I need to draw different text strings in a later loop, I reuse as many of the existing indexes as possible and just change their string values, colors, positions, etc. In fact, you don't want to draw and delete text every loop anyway as this can introduce a significant performance drop. Instead, it's best to keep as many existing indexes in place and just hide or show them when needed. Just change their string values if/when needed rather than recreating them entirely. This becomes more important the more text lines you try to draw. The text function looks something like this (using a global integer named 'TextNumber' that resets at the beginning of each loop to keep track of all text indexes being newly used for each loop and one named 'TextNumberOld' to keep track of the maximum number of indexes used to clear only the unused indexes at the end of each loop):



And at the end of each loop, I clear the text with this so it doesn't persist:



This keeps things sorted so you don't clear/reset indexes unnecessarily, good for potentially a 20-30% performance increase if you have a text heavy render that needs frequent changes.
Ermesjr
User Offline
Joined: 11th Feb 2021
Location:
Posted: 18th Feb 2021 18:37
I see, it's a different path, you've to left what you know for the unknown....

@SFSW

I see you're sure a master of AppGameKit, and with yout 18 years of career, you're for sure a master of DBPro and maybe even DBC.

my compliments,

i've to work about it, delete all what i've learned, and start from zero again

thanks, Ermes
n00bstar
17
Years of Service
User Offline
Joined: 9th Feb 2004
Location: Montreal, Canada.
Posted: 19th Feb 2021 10:35
You'll find there are many ways to go about it. Depending on your specific needs, it might make more sense to do it one way or another. Some methods yield a faster overall framerate, some are simpler and need less planning/management. Maybe you'll come up with a way that brings the FPS from 800 to 200 and you won't care about the framerate hit because you're going to cap it all off at 60 anyways. Maybe you find a way that keeps your FPS at 800 all the time but the GPU fan is spinning at full speed all the time. Experiment, find what's best for you and your project
-----------------------------------------------------------------------------
We all got a chicken duck woman thing waiting for us
Ermesjr
User Offline
Joined: 11th Feb 2021
Location:
Posted: 19th Feb 2021 21:20
well, my take was always to be as fast as possible, in framerate.

Butr... i'm very green on AppGameKit at the moment, i don't care at FPS right now.

Sadly for me in this new begin, the taste that remains in my mouth is of an incomplete program. Sometimes i think it's like carving Michelangelo's piety with an awl. it's frustation i know.

But we can use it for sure, and make great works.

thanks dudes.

Ermes
Samrich
User Banned
Posted: 19th Mar 2021 11:07
Thanks a lot for these posts. They really helped me out.
PartTimeCoder
AGK Tool Maker
6
Years of Service
User Offline
Joined: 9th Mar 2015
Location: Suffolk UK
Posted: 20th Mar 2021 10:07
Internal Sprite and Object management are one of AGK's strengths not weakness, go make a game with (most) other frameworks and first you got to code a sprite/object/text management system before you place a single item in your world, sure if you code it yourself then you can optimize the hell out of it.

The point of a framework like AppGameKit is abstraction and it does that pretty dam well.

Login to post a reply

Server time is: 2021-04-14 09:56:26
Your offset time is: 2021-04-14 09:56:26