SUGGESTION: Raw Draw on Sprites and stuffs

[Gilbert]

This had been discussed a bit on, and I think I'll start a new thread for it now.

History:
Since the releases of the V2.57 betas, you can now dynamically  create new sprites in game via loading external graphic files or screenshots saved in savegame files. This sprites can be created and destroyed dynamically in game, and have their sprite slot numbers assigned fuzzily (like the overlays) and are not controlled by the sprite cache buffer, any addition of such kind of sprites will consume physical memory.

Drawbacks:
1. Since the Animation Views cannot be dynamically modified currently, those dynamically created sprites cant be used in animated stuffs using Views, so it is not suitable for characters and such, only suitable for overlays, objects, or raw draw sprites on backgrounds.
2. Currently no way to set whether the created sprite is hires or not.

Possible solution:
1. First, since we can now have 2 types of sprites in game, those controlled by sprite cache and those which are not ('dynamic' ones), I suggest that one more option can be added to sprites in the sprite manager of AGSEdit, the "Can be modified in game" checkbox option, when a sprite has this option checked, it's not controlled by the sprite cache in game, so it MUST be loaded into physical memory when the game starts (so it will consume much memory if there're many/large such sprites, but that's the responsibility of the game creator himself to manage this), then these sprites can have their contents dynamically changed in game. The advantage of this is that now their sprite slot numbers are predefined and static, thus can be used in Views, and that you can set in AGSEdit already whether they are hires or not.

2. Additionally extending the ability of the raw functions to draw on sprites can be useful (eg making custom character graphics). Suggested new functions:

CreateBlankSprite(int width, int height, int fillcolour, int hires)
Create a blank sprite of dimension width * height filled with fillcolour (-1 for transparent) which can be drawn on, and if hires is non-zero, the sprite is created as high res ( (2*width) * (2*height) screen pixels), returns the slot number of the newly created sprite if successful, returns -1 if failed.

RawXXXSprite(Blargh)
Basically make most of the BG Raw Draw functions work for dynamically assigned sprites (ie., those created by LoadImageFile(), LoadSaveSlotScreenshot(), CreateBlankSprite() or set to be editable in the sprite manager, attempt to draw to other "static" sprites would cause an error). Considerations are:
(a) the coordinates used in these functions are pixel perfect according to the sprite content itself, so you can draw hires graphics on hires sprites, say for example. If in case the functions draw in areas outside of the legal sprite size, the results are cropped.
(b) pass colour as -1 to draw transparent colour.

Suggestion 2 may be tricky to implement, but I think even if only 1 was implemented, it can still be useful.

[Pumaman]

This is an interesting idea. Suggestion 1 would be quite easy to implement, but it's not much use without suggestion 2 also being done.

The real question is, how many people would find it useful? The basic idea is that you would be able to dynamically RawDraw onto sprites in the game - would this be a feature you'd use?

[Gilbert]

Actually implementing just 1 can be quite useful already, as I pointed out:
a) The memory must be allocated at game start up, so wouldn't experience a crash or memory leak or whatever due to not enough memory if you want to create a new sprite in game.
b)  their sprite slot numbers are predefined and static, thus can be used in Views, without modifying the system.
c) you can set in AGSEdit already whether they are hires or not, again no additional modifications required.
d) can simplify some scripts, for example, with a loadgame GUI with screenshots, you don't need to create newsprite by loading a shot --> change sprite on GUI, instead, you can just load the shot on a sprite already placed on the GUI.

[Pumaman]

However, since images can't be loaded into a specific slot, and specific slots can't be drawn on, you wouldn't be able to do anything with them

[Gilbert]

hehe so what I meant was to accomany with a set of functions to load graphic files and savegameshots onto these sprites , but however that as the sizes of these sprites were fixed already, so it's the responsibility of the person who write the game to take care of the image sizes. Or if possible, make the functions:

LoadImagefiletoSlot(int slot, string filename) - loads an external image file with name "filename" to sprite slot "slot", the sprite must had the "Can be modified in game" checkbox checked in the sprite manager, otherwise there would be an error. if the dimension of the image file is different from the original sprite, the image would be padded with transparent pixels or cropped while necessary. Returns 0 if sucessful, and nonzero otherwise (eg file not found, etc).

LoadSaveSlotScreenshotToSlot(int slot, int saveslot) - Loads the screenshot for save game SAVESLOT into sprite slot "slot", resizing it to teh dimension of the sprite, the sprite must had the "Can be modified in game" checkbox checked in the sprite manager, otherwise there would be an error.
Returns 0 if sucessful, and nonzero otherwise (eg file not found, perhaps the save game didn't include one, etc).

In order for this to work, the "Save screenshots in save games" option must be ticked in the main Game Settings pane

[Pumaman]

Yep good point, you'd need something like those functions. I'm not yet convinced though that enough people would find it useful to go to the effort of adding this feature. We'll see.