Memory-functions (Undo/Redo)

[ReneMiner]

My problem today is the following:

(OK, I could have appended this to the bound-array-thread, but it's not about arrays in general. pray for the day that I have no problem and help solving other tB-users problems instead, but that might come since I use thinBasics just a few days but that about 18 to 30 hours per day ;) )

I'm currently creating a simple 3d-drawing app.
since the subarrays in UDT's are not dynamic, I use a few arrays, so there's

-one dynamic array for colors (type TBGL_tRGB)
-one dynamic array for the Normals(UDT, 3 doubles x,y,z)
-one dynamic array for the Vertex-positions , same type as normals
-one dynamic for the triangles (large UDT, consists of 3 arrays to store the indices for color ,normals and positions and a few states)
-plus four long variables to store the array-element-count of all that,
-and one string that is the name of the picture.

My brain is totally used to capacity with handling 3d-rotations, translations, matrices and ordering triangles , so I have no idea to solve this:

I need to create an Undo/Redo-function so the user can restore old conditions of his 3d picture, consisting of the above described elements. It should save a few states so user can go a few steps back and redo also.

It will have a few days of time until it comes to coding that, but it will...

has anybody some smart idea how to store and retrieve all that in correct order? I just know the point in my code, where I have to create a new Undo-state...

[Petr Schreiber]

Hi Rene,

the Undo/Redo is tough, I know I struggled with it in editor before ThinEdge.

I know two possible approaches:
#1 Record operations
This approach is based on creating log of everything user does. In my program ModelEd, when user created triangle, it created this log in memory
%MED_VERTEXADD, -1, -1, 0
%MED_VERTEXADD, 1, -1, 0
-> %MED_VERTEXADD, 0, 1, 0

HistoryCursor = 3

So, when user selected Undo, I checked the last item, which was {%MED_VERTEXADD, 0, 1, 0}, saw the operation was vertex addition, and I performed inverse operation, that is vertex deletion, and decreased historyCursor, so the record was changed to:
%MED_VERTEXADD, -1, -1, 0
-> %MED_VERTEXADD, 1, -1, 0
%MED_VERTEXADD, 0, 1, 0

HistoryCursor = 2

This approach has advantage it allows both undo and redo, but it had quite huge memory requirements for big meshes.

#2 Brute force memory backup
This is the most straightforward method - after each operation, you take memory representation of your model using PEEK$, and store it to numbered temporary file on disk. When you do Undo, you find last file, grab its contents and put it via POKE back to memory. Easy, fast... and huge hard drive eater :)


Petr

[ReneMiner]

second method seems easier to me. I already thought about something like that but I feared the many drive-accesses. but this might be a method to restore even the states of the last session, and I don't need an explicit save-at-end routine, since the state is already on the drive.

my first thoughts were to put them somewhere in memory with indexed memory-pointers, which would be dynamic udt-arrays also...but that
is filling memory with a lot of data, and could lead -at least with 3d, which has a lot of data to store (around 40,50 bytes per vertex) to an out-of-memory. so i might save around 100 states and then overwrite them from the beginning. this i can handle, thanks for brightening my brains :cool:
René