#yup

1 messages · Page 1 of 1 (latest)

marsh night
#

ooo I would really appreciate any tips or anything really, I'm trying to get better at coding so the more complex the better

fast lily
#

first, i got custom code a custom data structure called a DropoutStack. A DropoutStack is a Stack, with a max size, and if you try to push something onto the DropoutStack when it is at max capacity, it erases the bottom of the stack.

#

This DropoutStack is the core of the structure

fast lily
#

In my case, it was an Undo/Redo log for level editor, called a BuildHistory. Next, we make a simple Class for a BuildHistoryEvent. It is a single unit of (everything that happens within one click of undo/redo)

#

This is going to be like a command pattern. However you make a BuildHistoryEvent, it just needs to contain all the information to do a single undo/redo call.

#

Then, we have a 3rd class, called BuildHistory. BuildHistory’s job is to maintain a DropoutStack<BuildHistoryEvent> for undo history, and DropoutStack<BuildHistoryEvent> for redo history.

#

BuildHistory’s job is to basically manage that, tell is can we undo, can we redo, and when we undo/redo, it spits out a BuildHistoryEvent for us to do.

#

BuildHistory does not actually DO the Undo/Redo. It just keeps a log, to spit out the event that needs to happen.

#

Do you follow so far?

#

you’re typing a lot for a simple yes or no

marsh night
#

I'm a bit confused on sort of the way it works, there's a stack which contains and lets us grab the "info", there's an event that lets us "send" info, and there's one that sends the "action" to be done?

fast lily
#

the stack keeps the order of what to do

#

If we were to do separate actions for typing: L E F T.
Then the Undo log looks like:
Bottom - erase char 1, erase char 2, erase char 3, erase char 4 - Top

#

now I undo. I pop the top of the undo stack, which is a T, and spit out what happened. I then push the equivalent event to the redo stack.

#

Undo: Bottom - erase char 1, erase char 2, erase char 3 - Top
Redo: Bottom - add “T” - Top

#

Does this make sense?

#

One build history event contains the information for what we need to do to go backwards from one state to the previous

#

I could explain how it worked for my level editor, which writes to a tilemap

marsh night
#

I think that I got the idea with the characters, the only thing I can't understand yet is the "spit" part, how do you redo it?

fast lily
#

Whenever you undo, you also log to the redo

marsh night
#

Yup, I mean how do you redo the action?

fast lily
#

maybe I can explain

marsh night
#

So like write the T character back in?

#

Is there like a way to do the "opposite" of the undo, or is it just a method like "if stack info = character: write character to console"?

fast lily
#

in my case, i have a tilemap. I write tiles and erase tiles. My super low level functions, when they make an edit, they make a log “coordinate X contained tile Y” (and Y could be null). My BuildHistoryEvent is a list of every individual tile changed

fast lily
#

My BuildHistory has a few methods:
StartLoggingUndoEvent, StartLoggingRedoEvent, StopLoggingEvent, and LogPriorTile

#

BuildHistory keeps a current BuildHistoryEvent that is currently growing, if we are in the middle of writing an event.

#

Whenever my game starts a new drawing action, I call StartLoggingUndoEvent

#

All of my edit functions (for draw/erase) call LogPriorTile on BuildHistory before we actually make the edit.

#

So BuildHistory adds the old tile into the growing event.

#

When done drawing, we call StopLoggingEvent

#

which pushes the complete event onto the Undo DropoutStack.

#

Follow so far?

marsh night
#

Yup

fast lily
#

When we call Undo, we:

  1. Pop from the Undo DropoutStack
  2. Call StartLoggingRedoEvent
  3. Go do all the edit functions to draw whatever is in the BuildEvent we are undoing. Every edit function (when called) calls LogPriorTile (like before). So the growing BuildHistoryEvent gets populated with what the board was before we undo anything.
  4. Call StopLoggingEvent. Since BuildHistory was logging a redo event, it pushes this to the redo stack.
#

this effectively adds the reverse to the redo stack

#

i forget the details, since I can’t access my code rn, but that is the basic idea.

#

Also, fight any temptation for BuildHistory to actually DO any of the changes. That is shit design, and everything will spiral out of control if you do that

#

Unfortunately, my computer got fried last week, so I can’t just send you code for some of these data structures.

marsh night
#

okay okay, I'll try to do something similar, if I have any issue would u be ok helping me out a bit?

fast lily
#

yeah, just ping me

marsh night
#

alr alr, tysm man smiley face

fast lily
#

btw, obvious first order of business is to write code for a dropout stack