tag:blogger.com,1999:blog-1096533244660546051.post2719761817518383351..comments2023-08-24T06:18:07.649-07:00Comments on Oren Game Engine: Undo/Redo Systemorenk2khttp://www.blogger.com/profile/17368325567494358231noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-1096533244660546051.post-60743411412535102152009-08-04T00:14:24.993-07:002009-08-04T00:14:24.993-07:00hi
1. implementation decision
2. not exactly
first...hi<br />1. implementation decision<br />2. not exactly<br />first we have a limited frames! in our prob' its scene snapshots. <br />second, we don't really capture fullscreen real-time frame with sound that needs a constant 25-60 fps, so if you compare the data we store in video capturing and the data we store if you take full snapshot (not that i say i'm doing that but still...) its really not an issue!<br />but still, its all depend on the app, if your object have 100 kb of data, its really a bad idea to take full snapshot of 100 objects! its ridiculous.orenk2khttps://www.blogger.com/profile/17368325567494358231noreply@blogger.comtag:blogger.com,1999:blog-1096533244660546051.post-23019641113168766112009-08-03T11:48:00.525-07:002009-08-03T11:48:00.525-07:00Oren
1. i thought too that sync issues are out of ...Oren<br />1. i thought too that sync issues are out of place here, so i don't understand what Undo_start and Undo_End are for.<br />2. The video analogy actually demonstrates my point. you can *almost never* afford to store full states of real-life-size objects (be it scene or frame). Especially today, that games tend to have vast scenes, this really should be a major engine/editor design consideration.Ofek Shilonhttps://www.blogger.com/profile/08928704124269681648noreply@blogger.comtag:blogger.com,1999:blog-1096533244660546051.post-90177558081611376882009-08-03T00:09:21.126-07:002009-08-03T00:09:21.126-07:00hi dude
1. the sync thing you mentioned, well... ...hi dude<br /><br />1. the sync thing you mentioned, well... not the main prob' right now (i don't think it will because the design) the only threads i think i will use is for the build process, loading etc...<br /><br />2. as i wrote, it all comes to the snapshot func, there are many ways to do it and one way is like you mentioned, you could basically inherent from some base class of undo/redo system that track the changes of the objects, this class allows the object to override few functions and let it implement its own undo/redo func, for example: if your object apply a transformation matrix, lets say move or rotate (lets call it 'the action'), so the object must implement the 'undo action' by using the inverse of that matrix... i didn't like this design, because it tend to become very hard to maintain and its not generic in a way that every object needs to implement its own undo/redo functions... <br />note its all depends on the app, there also few ways to do full/half snapshots, what i wrote is just a simple solution for every one to start with, but in real app or commercial one you must take care and optimize things.<br />some thing to think about:<br />when you video capturing (i'v the chance to write one, at my work...) you don't save every image by itself right? you can save deltas or whatever, you can also compress the data, you can do tons etc...<br />the more you work on the data to make it smaller, the more it become slower to decode, so you need to trade off speed versus memory.<br />its not a video capturing, but the idea is the same, we need to capture scene states instead of scene pixels ;)<br /><br />i'm glad to hear you are still enjoying my posts...<br />thanks and byeorenk2khttps://www.blogger.com/profile/17368325567494358231noreply@blogger.comtag:blogger.com,1999:blog-1096533244660546051.post-24368411388900192052009-08-02T11:17:53.937-07:002009-08-02T11:17:53.937-07:00Naftali! always great to read your stuff. I'l...Naftali! always great to read your stuff. I'll be implementing undo/redo functionality myself soon, and just wanted to add my 2cents:<br />Seems your main focus is synchronization issues. is undo/redo such a lengthy op that you do it in a separate thread? can't you let windows messages sort out the sync issues for you? <br />Another thing - in our scenario, (and many others) the space complexity of holding N complete scene layouts is prohibitive. The usual design of undo/redo works around this by storing every modification as an object, that encapsulates just the deltas needed to undo/redo itself (i.e., must implement undo() and redo() ). I recently learnt this design actually has a name: http://en.wikipedia.org/wiki/Command_pattern.Ofek Shilonhttps://www.blogger.com/profile/08928704124269681648noreply@blogger.com