Dev Info: MultiFramed Undo (Stu, read this!)

Banshee

I've changed the structure of TUndoRedo to accept multiples frames.

The structure has changed to this:

Code:

type
TUndoRedo_Item = record
X : integer;
Y : integer;
Colour : byte;
end;

TUndoRedo_Frames = array of packed record
Num : cardinal;
FrameID : smallint;
Items : array of TUndoRedo_Item;
end;

TUndoRedo_Items = array of packed record
Num : cardinal;
Frames : TUndoRedo_Frames;
end;

TUndoRedo = record
Num : cardinal;
Items : TUndoRedo_Items;
end;

I believe you can understand this very well. I only wanna point out that FrameID (which used to be called Frame) has changed to smallint because no descent C&C modder will put more than 32768 frames in his SHP. I buildup with more than 32768 frames would take over a minute in most of computers to finish. Any superweapon effect with 32768 frames would be possible, but it's also crazyness and I know that humans won't have patience to work on 32768 frames or more... unless they wanna make a movie, but BS SHP Builder isnt made for movies.

I applied this new concept to make the undo to Colour Replacement and Pal Pack (after I got seriously pissed off by loosing my pretty ninja scorpion sniper Neutral

). I made 2 new procedures to allow it to add different points into the same undo item:

procedure GenerateNewUndoItem(var UndoRedo : TUndoRedo);
procedure AddToUndoMultiFrames(var UndoRedo : TUndoRedo; framenumber:smallint; xpos,ypos:smallint; colour:byte);

The first one generates the new undo item. Add it before the loop. The second one adds the values of a pixel to the last undo item and goes inside the loop. In the end of the process, you just need to run FrmMain.UndoUpdate; to add it to the Undo list.

Here's a sample from the latest Colour Replacement code:

Code:

GenerateNewUndoItem(UndoList);
// Recolour Image
for Frame := FS to FE do
begin
ProgressBar1.Position := Frame;
//ProgressBar1.Refresh;
for x := xstart to xend do
for y := ystart to yend do
begin
AddToUndoMultiFrames(UndoList,Frame,x,y,FrmMain.SHP.Data[Frame].FrameImage[x,y]);
FrmMain.SHP.Data[Frame].FrameImage[x,y] := colours[FrmMain.SHP.Data[Frame].FrameImage[x,y]];
end;
end;

FrmMain.UndoUpdate;

I still have to add an undo code for resize, add frame and remove frame (since these features can cause a havoc in the undo, if they are used).

Btw, I have a bad news for BS SHP Builder users: Pal Pack and Colour Replacement will take half a second more to load... sorry #Tongue

, but it's for your own safety.

stucuk · Geek **Joined**: 27 Aug 2002

U should the TTempView to store the data and pass that to a procedure that adds it to the undo thing, thus u don't waste ppls Ram storing pixels that havn't changed.

Thoughtu were mr optimise.

P.S u sure everything still works?

_________________
Free Map Editor - Game Requirements - Stucuk.Net

Banshee · Posted: Wed Mar 24, 2004 3:44 pm Post subject:

Actually, this undo system allows us to only store the modified pixels, but I've just noticed that my colour replacement code really stores every pixel. Maybe I should do a 'pixel check' to save memory...

stucuk · Geek **Joined**: 27 Aug 2002

so the original undo procedures n functions are still working fine, u just modifyed them to account for the fact u can use frames now ?

_________________
Free Map Editor - Game Requirements - Stucuk.Net

Banshee · Posted: Thu Mar 25, 2004 12:59 pm Post subject:

The original undo stuff appears to work fine here. I did some tests and found out no problems so far.

_________________

Mods, Mods Support, Public Researchs, Map Archives, Tutorials, A Friendly Community and much more. Check it out now!

stucuk · Geek **Joined**: 27 Aug 2002

u should try n make a new procedure/function that uses an array of TTempView's to generate a multipul frame undo adding thingy.

note: frame numbers would b stored in an array of integer, and the total number of frames affected would b stored in an integer.

The reason for using TTempView is that it is a small and compact way to store GFX data.

_________________
Free Map Editor - Game Requirements - Stucuk.Net

Banshee · Posted: Thu Mar 25, 2004 9:38 pm Post subject:

No, actually, I prefer the format above. The functions for multiframed are correct, but I added a verification in the end of the loop that checks if something was added and delete the latest generated item if nothing was added, otherwise we would have a corrupted item.

Also, talking about 'corrupted item', I did a little hack that made the program undo inserted and deleted frames through 'corrupted items'. It detects when the first frame has no items and deals in a special way with these frames. I just need to extend this function now to accept your way to deal with shadow frames. Otherwise the program will do crap by forgetting to delete or insert previous shadow frames #Tongue

. I'll do it soon.

_________________

Mods, Mods Support, Public Researchs, Map Archives, Tutorials, A Friendly Community and much more. Check it out now!

devin11590 · Cyborg Artillery **Joined**: 23 Mar 2003 **Location**: USA

no need to save memory here (i have a gig) but not everyone has that much so i guess it is kinda important

_________________
Please, read the signature rules of the forum.

stucuk · Geek **Joined**: 27 Aug 2002

u need to use something like the TTempView or u will b storing a hell of alot of unchanged crap.

_________________
Free Map Editor - Game Requirements - Stucuk.Net

Banshee · Posted: Fri Mar 26, 2004 9:55 pm Post subject:

No, I'm not storing any unchanged crap.

_________________

Mods, Mods Support, Public Researchs, Map Archives, Tutorials, A Friendly Community and much more. Check it out now!

stucuk · Geek **Joined**: 27 Aug 2002

when it comes to the colour replacer there is no need for sorting anything, its easy to make it use a system like the ttempview or use the actual ttempview system.

_________________
Free Map Editor - Game Requirements - Stucuk.Net