Menu
▾
▴
exult-general
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(55) |
May
(407) |
Jun
(233) |
Jul
(365) |
Aug
(565) |
Sep
(109) |
Oct
(91) |
Nov
(712) |
Dec
(239) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(311) |
Feb
(178) |
Mar
(304) |
Apr
(150) |
May
(252) |
Jun
(175) |
Jul
(375) |
Aug
(259) |
Sep
(163) |
Oct
(121) |
Nov
(175) |
Dec
(119) |
| 2002 |
Jan
(262) |
Feb
(65) |
Mar
(164) |
Apr
(129) |
May
(241) |
Jun
(180) |
Jul
(123) |
Aug
(64) |
Sep
(47) |
Oct
(72) |
Nov
(92) |
Dec
(23) |
| 2003 |
Jan
(17) |
Feb
(55) |
Mar
(43) |
Apr
(61) |
May
(157) |
Jun
(69) |
Jul
(103) |
Aug
(301) |
Sep
(80) |
Oct
(55) |
Nov
(93) |
Dec
(121) |
| 2004 |
Jan
(131) |
Feb
(106) |
Mar
(52) |
Apr
(72) |
May
(134) |
Jun
(133) |
Jul
(33) |
Aug
(4) |
Sep
(17) |
Oct
|
Nov
(7) |
Dec
|
| 2005 |
Jan
(22) |
Feb
(3) |
Mar
|
Apr
(17) |
May
(5) |
Jun
(5) |
Jul
(28) |
Aug
(26) |
Sep
|
Oct
|
Nov
(13) |
Dec
(10) |
| 2006 |
Jan
(13) |
Feb
(10) |
Mar
(5) |
Apr
(8) |
May
|
Jun
|
Jul
(2) |
Aug
(8) |
Sep
(23) |
Oct
|
Nov
(1) |
Dec
(2) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(9) |
Jun
(11) |
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(11) |
| 2008 |
Jan
|
Feb
(6) |
Mar
|
Apr
(4) |
May
(15) |
Jun
|
Jul
(34) |
Aug
|
Sep
(5) |
Oct
|
Nov
(3) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(4) |
Apr
(1) |
May
(10) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
(19) |
Feb
(9) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
(10) |
Nov
(4) |
Dec
(9) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(13) |
Nov
|
Dec
(2) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2015 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(5) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(7) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(22) |
Dec
(3) |
|
From: Marzo J. <ma...@gm...> - 2018-12-22 12:13:56
|
Well, that went quicker than I expected. New branch is called 'devel-smart-ptrs'. I will probably create another branch to work on without conflicts. On Sat, 22 Dec 2018, 08:42 Marzo Junior, <ma...@gm...> wrote: > I have done script changes on master to that effect; and for Windows, on > the msys2 branches. And some OSX changes on the unique_ptr branch (because > libstdc++ is very ancient on OSX, and we have to use libc++ instead). > > I think now is a good time for some merging: over the weekend I will merge > sharedPtr with master into a new branch, then merge/cherry-pick unique-ptr > branch on top, then merge msys2-unique-ptr. After that, we can create new > branches from devel and go on working until it is time to merge again. > > I wonder why I could compile without hassle locally; I did notice the > build failures on Travis after the fact, but decided to postpone any > actions because they could complicate the merge. > > > On Sat, 22 Dec 2018, 01:37 jeff, <jef...@gm...> wrote: > >> Looks like we need c++ v14 now. Do we need to update our script(s)? I >> find I have to manually set CXXFLAGS when I build; otherwise I get v11. >> On 11/17/18 1:56 AM, Marzo Junior wrote: >> >> Hi Jeff, >> >> Just a heads up: when you feel it is time to merge to master, let me know >> and I will deal with the conflicts and do it. >> >> You will soon understand why... >> >> On Wed, Nov 14, 2018 at 2:48 AM jeff <jef...@gm...> wrote: >> >>> On 11/6/18 1:00 AM, Marzo Junior wrote: >>> >>> >>> 3. We can remove a lot of cleanup code with judicial use of smart >>> pointers. For example, time-sensitive objects remove themselves from the >>> time queue upon deletion. If we make the time queue hold weak_ptr, try to >>> turn it to a smart_ptr before doing the callback, and ignore all objects >>> that no longer exist, we can remove that cleanup code. Also, the whole code >>> for notifying schedules that an object was deleted. >>> >>> >>> I've just cleaned up the schedules using weak_ptr's, and it seems to >>> work. I still have problems with Object_list deletion, and think it will >>> be best if I stop having it be circular. >>> >>> >>> |
|
From: Marzo J. <ma...@gm...> - 2018-12-22 07:42:28
|
I have done script changes on master to that effect; and for Windows, on the msys2 branches. And some OSX changes on the unique_ptr branch (because libstdc++ is very ancient on OSX, and we have to use libc++ instead). I think now is a good time for some merging: over the weekend I will merge sharedPtr with master into a new branch, then merge/cherry-pick unique-ptr branch on top, then merge msys2-unique-ptr. After that, we can create new branches from devel and go on working until it is time to merge again. I wonder why I could compile without hassle locally; I did notice the build failures on Travis after the fact, but decided to postpone any actions because they could complicate the merge. On Sat, 22 Dec 2018, 01:37 jeff, <jef...@gm...> wrote: > Looks like we need c++ v14 now. Do we need to update our script(s)? I > find I have to manually set CXXFLAGS when I build; otherwise I get v11. > On 11/17/18 1:56 AM, Marzo Junior wrote: > > Hi Jeff, > > Just a heads up: when you feel it is time to merge to master, let me know > and I will deal with the conflicts and do it. > > You will soon understand why... > > On Wed, Nov 14, 2018 at 2:48 AM jeff <jef...@gm...> wrote: > >> On 11/6/18 1:00 AM, Marzo Junior wrote: >> >> >> 3. We can remove a lot of cleanup code with judicial use of smart >> pointers. For example, time-sensitive objects remove themselves from the >> time queue upon deletion. If we make the time queue hold weak_ptr, try to >> turn it to a smart_ptr before doing the callback, and ignore all objects >> that no longer exist, we can remove that cleanup code. Also, the whole code >> for notifying schedules that an object was deleted. >> >> >> I've just cleaned up the schedules using weak_ptr's, and it seems to >> work. I still have problems with Object_list deletion, and think it will >> be best if I stop having it be circular. >> >> >> |
|
From: jeff <jef...@gm...> - 2018-12-22 00:38:05
|
Looks like we need c++ v14 now. Do we need to update our script(s)? I find I have to manually set CXXFLAGS when I build; otherwise I get v11. On 11/17/18 1:56 AM, Marzo Junior wrote: > Hi Jeff, > > Just a heads up: when you feel it is time to merge to master, let me > know and I will deal with the conflicts and do it. > > You will soon understand why... > > On Wed, Nov 14, 2018 at 2:48 AM jeff <jef...@gm... > <mailto:jef...@gm...>> wrote: > > On 11/6/18 1:00 AM, Marzo Junior wrote: > >> >> 3. We can remove a lot of cleanup code with judicial use of smart >> pointers. For example, time-sensitive objects remove themselves >> from the time queue upon deletion. If we make the time queue hold >> weak_ptr, try to turn it to a smart_ptr before doing the >> callback, and ignore all objects that no longer exist, we can >> remove that cleanup code. Also, the whole code for notifying >> schedules that an object was deleted. >> >> > I've just cleaned up the schedules using weak_ptr's, and it seems > to work. I still have problems with Object_list deletion, and > think it will be best if I stop having it be circular. > > |
|
From: Jeff F. <jef...@gm...> - 2018-11-19 19:12:47
|
Okay, I'll let you know when I'm confident about it. On 11/19/18 9:31 AM, Marzo Junior wrote: > The warning is probably because of the temporary branch I created to > test Travis configurations. > > Regarding the merge, allow me to do it; I did offer to do it due to > the enormous push I made. > > On Mon, 19 Nov 2018, 18:29 Jeff Freedman, <jef...@gm... > <mailto:jef...@gm...>> wrote: > > Thanks! I'm still testing by playing Black Gate. There ARE bugs, > but they're easy to find and fix now (so far). I think the C++ > people did a nice job on this feature. > > BTW, I'm getting a strange git warning now when I do a 'push'. > Should I try to merge the mainline changes into my branch? > > On 11/19/18 12:46 AM, Dominik Reichardt wrote: >> I found some time to grab this branch and let it run during the >> night. The test case that reliably crashed for me is no longer >> crashing. Exult ran the whole night without a hang. >> >> However the shared pointers mean that it is the end of the line >> for PowerPC OS X. AFAICT libc++ is not available for PowerPC macs >> without a lot of hassle. This is just for your information. The >> last PowerPCs were sold in 2007, SDL2 is not available etc. It’s >> time to say goodbye. Another git tag that needs to be done to >> mark the point of no return, though :) >> >> Thanks for the hard work on this! >> >> Dom >> >>> On 18. Nov 2018, at 22:43, jeff <jef...@gm... >>> <mailto:jef...@gm...>> wrote: >>> >>> Uh oh. :-) >>> >>> Might be in a week. I'm playing through BG and finding bugs. >>> >>> On 11/17/18 1:56 AM, Marzo Junior wrote: >>>> Hi Jeff, >>>> >>>> Just a heads up: when you feel it is time to merge to master, >>>> let me know and I will deal with the conflicts and do it. >>>> >>>> You will soon understand why... >>>> >>>> On Wed, Nov 14, 2018 at 2:48 AM jeff <jef...@gm... >>>> <mailto:jef...@gm...>> wrote: >>>> >>>> On 11/6/18 1:00 AM, Marzo Junior wrote: >>>> >>>>> >>>>> 3. We can remove a lot of cleanup code with judicial use >>>>> of smart pointers. For example, time-sensitive objects >>>>> remove themselves from the time queue upon deletion. If we >>>>> make the time queue hold weak_ptr, try to turn it to a >>>>> smart_ptr before doing the callback, and ignore all >>>>> objects that no longer exist, we can remove that cleanup >>>>> code. Also, the whole code for notifying schedules that an >>>>> object was deleted. >>>>> >>>>> >>>> I've just cleaned up the schedules using weak_ptr's, and it >>>> seems to work. I still have problems with Object_list >>>> deletion, and think it will be best if I stop having it be >>>> circular. >>>> >>>> >> >> >> >> _______________________________________________ >> Exult-general mailing list >> Exu...@li... <mailto:Exu...@li...> >> https://lists.sourceforge.net/lists/listinfo/exult-general > _______________________________________________ > Exult-general mailing list > Exu...@li... > <mailto:Exu...@li...> > https://lists.sourceforge.net/lists/listinfo/exult-general > |
|
From: Marzo J. <ma...@gm...> - 2018-11-19 17:32:07
|
The warning is probably because of the temporary branch I created to test Travis configurations. Regarding the merge, allow me to do it; I did offer to do it due to the enormous push I made. On Mon, 19 Nov 2018, 18:29 Jeff Freedman, <jef...@gm...> wrote: > Thanks! I'm still testing by playing Black Gate. There ARE bugs, but > they're easy to find and fix now (so far). I think the C++ people did a > nice job on this feature. > > BTW, I'm getting a strange git warning now when I do a 'push'. Should I > try to merge the mainline changes into my branch? > On 11/19/18 12:46 AM, Dominik Reichardt wrote: > > I found some time to grab this branch and let it run during the night. The > test case that reliably crashed for me is no longer crashing. Exult ran the > whole night without a hang. > > However the shared pointers mean that it is the end of the line for > PowerPC OS X. AFAICT libc++ is not available for PowerPC macs without a lot > of hassle. This is just for your information. The last PowerPCs were sold > in 2007, SDL2 is not available etc. It’s time to say goodbye. Another git > tag that needs to be done to mark the point of no return, though :) > > Thanks for the hard work on this! > > Dom > > On 18. Nov 2018, at 22:43, jeff <jef...@gm...> wrote: > > Uh oh. :-) > > Might be in a week. I'm playing through BG and finding bugs. > On 11/17/18 1:56 AM, Marzo Junior wrote: > > Hi Jeff, > > Just a heads up: when you feel it is time to merge to master, let me know > and I will deal with the conflicts and do it. > > You will soon understand why... > > On Wed, Nov 14, 2018 at 2:48 AM jeff <jef...@gm...> wrote: > >> On 11/6/18 1:00 AM, Marzo Junior wrote: >> >> >> 3. We can remove a lot of cleanup code with judicial use of smart >> pointers. For example, time-sensitive objects remove themselves from the >> time queue upon deletion. If we make the time queue hold weak_ptr, try to >> turn it to a smart_ptr before doing the callback, and ignore all objects >> that no longer exist, we can remove that cleanup code. Also, the whole code >> for notifying schedules that an object was deleted. >> >> >> I've just cleaned up the schedules using weak_ptr's, and it seems to >> work. I still have problems with Object_list deletion, and think it will >> be best if I stop having it be circular. >> >> >> > > > _______________________________________________ > Exult-general mailing lis...@li...://lists.sourceforge.net/lists/listinfo/exult-general > > _______________________________________________ > Exult-general mailing list > Exu...@li... > https://lists.sourceforge.net/lists/listinfo/exult-general > |
|
From: Jeff F. <jef...@gm...> - 2018-11-19 17:29:24
|
Thanks! I'm still testing by playing Black Gate. There ARE bugs, but they're easy to find and fix now (so far). I think the C++ people did a nice job on this feature. BTW, I'm getting a strange git warning now when I do a 'push'. Should I try to merge the mainline changes into my branch? On 11/19/18 12:46 AM, Dominik Reichardt wrote: > I found some time to grab this branch and let it run during the night. > The test case that reliably crashed for me is no longer crashing. > Exult ran the whole night without a hang. > > However the shared pointers mean that it is the end of the line for > PowerPC OS X. AFAICT libc++ is not available for PowerPC macs without > a lot of hassle. This is just for your information. The last PowerPCs > were sold in 2007, SDL2 is not available etc. It’s time to say > goodbye. Another git tag that needs to be done to mark the point of no > return, though :) > > Thanks for the hard work on this! > > Dom > >> On 18. Nov 2018, at 22:43, jeff <jef...@gm... >> <mailto:jef...@gm...>> wrote: >> >> Uh oh. :-) >> >> Might be in a week. I'm playing through BG and finding bugs. >> >> On 11/17/18 1:56 AM, Marzo Junior wrote: >>> Hi Jeff, >>> >>> Just a heads up: when you feel it is time to merge to master, let me >>> know and I will deal with the conflicts and do it. >>> >>> You will soon understand why... >>> >>> On Wed, Nov 14, 2018 at 2:48 AM jeff <jef...@gm... >>> <mailto:jef...@gm...>> wrote: >>> >>> On 11/6/18 1:00 AM, Marzo Junior wrote: >>> >>>> >>>> 3. We can remove a lot of cleanup code with judicial use of >>>> smart pointers. For example, time-sensitive objects remove >>>> themselves from the time queue upon deletion. If we make the >>>> time queue hold weak_ptr, try to turn it to a smart_ptr before >>>> doing the callback, and ignore all objects that no longer >>>> exist, we can remove that cleanup code. Also, the whole code >>>> for notifying schedules that an object was deleted. >>>> >>>> >>> I've just cleaned up the schedules using weak_ptr's, and it >>> seems to work. I still have problems with Object_list deletion, >>> and think it will be best if I stop having it be circular. >>> >>> > > > > _______________________________________________ > Exult-general mailing list > Exu...@li... > https://lists.sourceforge.net/lists/listinfo/exult-general |
|
From: Marzo J. <ma...@gm...> - 2018-11-19 08:51:40
|
Maybe we can add another tag to the "C++03" commit? On Mon, 19 Nov 2018, 09:46 Dominik Reichardt, <do...@re...> wrote: > I found some time to grab this branch and let it run during the night. The > test case that reliably crashed for me is no longer crashing. Exult ran the > whole night without a hang. > > However the shared pointers mean that it is the end of the line for > PowerPC OS X. AFAICT libc++ is not available for PowerPC macs without a lot > of hassle. This is just for your information. The last PowerPCs were sold > in 2007, SDL2 is not available etc. It’s time to say goodbye. Another git > tag that needs to be done to mark the point of no return, though :) > > Thanks for the hard work on this! > > Dom > > On 18. Nov 2018, at 22:43, jeff <jef...@gm...> wrote: > > Uh oh. :-) > > Might be in a week. I'm playing through BG and finding bugs. > On 11/17/18 1:56 AM, Marzo Junior wrote: > > Hi Jeff, > > Just a heads up: when you feel it is time to merge to master, let me know > and I will deal with the conflicts and do it. > > You will soon understand why... > > On Wed, Nov 14, 2018 at 2:48 AM jeff <jef...@gm...> wrote: > >> On 11/6/18 1:00 AM, Marzo Junior wrote: >> >> >> 3. We can remove a lot of cleanup code with judicial use of smart >> pointers. For example, time-sensitive objects remove themselves from the >> time queue upon deletion. If we make the time queue hold weak_ptr, try to >> turn it to a smart_ptr before doing the callback, and ignore all objects >> that no longer exist, we can remove that cleanup code. Also, the whole code >> for notifying schedules that an object was deleted. >> >> >> I've just cleaned up the schedules using weak_ptr's, and it seems to >> work. I still have problems with Object_list deletion, and think it will >> be best if I stop having it be circular. >> >> >> > _______________________________________________ > Exult-general mailing list > Exu...@li... > https://lists.sourceforge.net/lists/listinfo/exult-general > |
|
From: Dominik R. <do...@re...> - 2018-11-19 08:46:52
|
I found some time to grab this branch and let it run during the night. The test case that reliably crashed for me is no longer crashing. Exult ran the whole night without a hang. However the shared pointers mean that it is the end of the line for PowerPC OS X. AFAICT libc++ is not available for PowerPC macs without a lot of hassle. This is just for your information. The last PowerPCs were sold in 2007, SDL2 is not available etc. It’s time to say goodbye. Another git tag that needs to be done to mark the point of no return, though :) Thanks for the hard work on this! Dom > On 18. Nov 2018, at 22:43, jeff <jef...@gm...> wrote: > > Uh oh. :-) > > Might be in a week. I'm playing through BG and finding bugs. > > On 11/17/18 1:56 AM, Marzo Junior wrote: > >> Hi Jeff, >> >> Just a heads up: when you feel it is time to merge to master, let me know and I will deal with the conflicts and do it. >> >> You will soon understand why... >> >> On Wed, Nov 14, 2018 at 2:48 AM jeff <jef...@gm...> wrote: >> >>> On 11/6/18 1:00 AM, Marzo Junior wrote: >>> >>>> 3. We can remove a lot of cleanup code with judicial use of smart pointers. For example, time-sensitive objects remove themselves from the time queue upon deletion. If we make the time queue hold weak_ptr, try to turn it to a smart_ptr before doing the callback, and ignore all objects that no longer exist, we can remove that cleanup code. Also, the whole code for notifying schedules that an object was deleted. >>> >>> I've just cleaned up the schedules using weak_ptr's, and it seems to work. I still have problems with Object_list deletion, and think it will be best if I stop having it be circular. |
|
From: jeff <jef...@gm...> - 2018-11-18 21:43:26
|
Uh oh. :-) Might be in a week. I'm playing through BG and finding bugs. On 11/17/18 1:56 AM, Marzo Junior wrote: > Hi Jeff, > > Just a heads up: when you feel it is time to merge to master, let me > know and I will deal with the conflicts and do it. > > You will soon understand why... > > On Wed, Nov 14, 2018 at 2:48 AM jeff <jef...@gm... > <mailto:jef...@gm...>> wrote: > > On 11/6/18 1:00 AM, Marzo Junior wrote: > >> >> 3. We can remove a lot of cleanup code with judicial use of smart >> pointers. For example, time-sensitive objects remove themselves >> from the time queue upon deletion. If we make the time queue hold >> weak_ptr, try to turn it to a smart_ptr before doing the >> callback, and ignore all objects that no longer exist, we can >> remove that cleanup code. Also, the whole code for notifying >> schedules that an object was deleted. >> >> > I've just cleaned up the schedules using weak_ptr's, and it seems > to work. I still have problems with Object_list deletion, and > think it will be best if I stop having it be circular. > > |
|
From: Marzo J. <ma...@gm...> - 2018-11-17 09:56:39
|
Hi Jeff, Just a heads up: when you feel it is time to merge to master, let me know and I will deal with the conflicts and do it. You will soon understand why... On Wed, Nov 14, 2018 at 2:48 AM jeff <jef...@gm...> wrote: > On 11/6/18 1:00 AM, Marzo Junior wrote: > > > 3. We can remove a lot of cleanup code with judicial use of smart > pointers. For example, time-sensitive objects remove themselves from the > time queue upon deletion. If we make the time queue hold weak_ptr, try to > turn it to a smart_ptr before doing the callback, and ignore all objects > that no longer exist, we can remove that cleanup code. Also, the whole code > for notifying schedules that an object was deleted. > > > I've just cleaned up the schedules using weak_ptr's, and it seems to > work. I still have problems with Object_list deletion, and think it will > be best if I stop having it be circular. > > > |
|
From: jeff <jef...@gm...> - 2018-11-14 01:49:09
|
On 11/6/18 1:00 AM, Marzo Junior wrote: > > 3. We can remove a lot of cleanup code with judicial use of smart > pointers. For example, time-sensitive objects remove themselves from > the time queue upon deletion. If we make the time queue hold weak_ptr, > try to turn it to a smart_ptr before doing the callback, and ignore > all objects that no longer exist, we can remove that cleanup code. > Also, the whole code for notifying schedules that an object was deleted. > > I've just cleaned up the schedules using weak_ptr's, and it seems to work. I still have problems with Object_list deletion, and think it will be best if I stop having it be circular. |
|
From: Jeff F. <jef...@gm...> - 2018-11-09 18:23:34
|
I've been making progress on this. But there are a few problem areas: One is that lots of code moves an object, something like this: obj->remove_this(1); // Remove but don't delete. container->add(obj); At the first 'remove', the object disappears. So I've changed this to where you have to have a shared pointer: Game_object_shared keep; obj->remove_this(&keep); // Keep is set from obj->shared_from_this(); This keeps the object around until it gets added back. I've got to the point where Trinsic comes up, and the opening scene runs for a few seconds before crashing. I'm using valgrind to find corruption problems. On 11/6/18 1:00 AM, Marzo Junior wrote: > Hi Jeff, > > That is basically it, yes; but let me rephrase your 3 points in a way > that may be helpful: > > At the top of any call chain, we want to start from either a weak_ptr > and turn it to a shared_ptr, or with a shared_ptr. Once we have a > shared_ptr, we can pass down raw (non-smart) pointers. Whenever we > need to pass a pointer outside of the call chain, we should pass a > weak_ptr or a shared_ptr; and this is where enable_shared_from_this is > useful, as it enables us to convert a pointer (which we know is valid > due to the shared_ptr at the top of the call chain) to a shared_ptr or > to a weak_ptr. > > Does that sum up nicely your points? > > If so, yes, this will work perfectly and guarantee that we don't hold > references to dead objects. > > A few considerations: > > 1. For exception safety reasons, shared_ptr should be created using > make_shared, and unique_ptr with make_unique (c++14 only, but easily > emulated in c++11: we can literally just copy the code and it will > work). Using make_shared is slightly faster (it needs only one memory > allocation), and reduces the number of bare "new" in the codebase; it > has the disadvantage that the whole object memory will only be > deallocated when the last reference (weak or strong) goes away. > > 2. As a rule, shared_ptr, weak_ptr, and unique_ptr should not be > explicitly reset when leaving the scope/in destructors (this defeats > their purpose). The exception is when you have a chain of them (each > one holding the last/only reference to the next) and you want to > guarantee that you will not have a stack overflow. For Game_object, > this is relevant for the owning chunk/object. > > 3. We can remove a lot of cleanup code with judicial use of smart > pointers. For example, time-sensitive objects remove themselves from > the time queue upon deletion. If we make the time queue hold weak_ptr, > try to turn it to a smart_ptr before doing the callback, and ignore > all objects that no longer exist, we can remove that cleanup code. > Also, the whole code for notifying schedules that an object was deleted. > > After messing around with the code, I've come to a few realizations: > > 1. Just changing everything to shared_ptr<Game_object> isn't by > itself going to solve our problem, which is that we store > references to objects in schedules (and other places), but those > objects might be deleted from the world. When this happens > currently, it can result in memory corruption, because we free the > objects' memory. So if the schedule moves or changes the object, > it ends up writing over something else. So probably, schedules > would store weak_ptr's to objects and query them before doing > anything. The query would not only be to see if the object still > exists, but that it is still in the world (or on an NPC). > > 2. There are only two actual owners of an object: The Map_chunk > that contains it, or a Container_game_object (like a chest or NPC) > that it is within. Those are probably the only places where we > have to store a shared_ptr. All (or most) others should be > weak_ptr's. > > 3. If we inherit Game_object from std::enable_shared_from_this, > then we can always get a shared or weak pointer from a 'raw' > Game_object. So we don't have to modify all the code to use and > pass shared_ptr's. (I'm not sure about this; but if it's true, we > won't have as much of a performance hit, and this won't be all > that difficult a project.) > |
|
From: Marzo J. <ma...@gm...> - 2018-11-09 07:12:54
|
To be fair, I have been thinking of implementing some things in weather: * Serialization/deserialization: so that weather is kept as is when you save and reload the game, instead of restarting. * Wind effects: direction, speed, gusts of wind, the works. Basically, handles moving clouds, and maybe also affect rain/snow stops. Doing this because you can sometimes have multiple clouds moving in different directions. * Intrinsics to check/change wind effect. This would allow implementing a U6-like balloon what does not move against the clouds. On Fri, 9 Nov 2018, 00:51 jeff, <jef...@gm...> wrote: > :-) Maybe we should implement those too. > On 11/8/18 2:52 PM, Dominik Reichardt wrote: > > Just for laughs and because it fits. A 2014 interview with Bill Randolph, > lead programmer on Ultima 9: > > UC: And tying back to what you had said earlier, I imagine that if you > were already dealing with battling Windows for precious chunks of data > storage, that saving the state of this barrel — which I’ve now turned from > one object into about four, and then moved those four pieces around — I can > only imagine that the whole caching in/caching out was just Hell on Earth. > > BR: Yes. Oh, I have a great story for you, now that you’ve reminded me of > this. > > One of the other things I worked on in the game was the hanging signs. And > I don’t know…let me call your attention, in Ultima 9, to those hanging > signs, because they’re awesome. They started out as…it was just an example > of something Richard wanted because it was interactive. He wanted you to be > able to tap a hanging sign and have it swing, okay? And so I put in logic > that was just a simple oscillation…and we looked at that and thought: > “that’s terrible.” So I actually added physics to it; I added exponential > decay. And then I added a little bit of a yaw element to it. > > And then we added wind, so that when there were multiple signs in the > town, and the wind blew, they would all blow, and kick in, and swing. And > you could shoot an arrow into the sign, and it would react to the arrow you > shot; I don’t know if you ever tried that. But try it sometime, shoot an > arrow into a sign. > > Anyway, we had one of these signs that was swinging in the wind (laughs) > and it was just at the end of what we called the “fast area”, which was the > area cached in around you that updates, and the area outside of that is > cached out and saved to disk. Well, this sign swung and crossed a boundary, > and dropped out of the fast area…crunch!…saved to disk. And the little > controller that was running it crashed. “Where’s my object?” So that was > just one example of the kind of…oh my gosh, this game was unbelievably > complicated. > > > whole interview > http://ultimacodex.com/interviews/an-inertia-of-legend-an-interview-with-bill-randolph/ > > On 7. Nov 2018, at 02:06, Jeff Freedman <jef...@gm...> wrote: > > Yes, that's it. And I think it could be phased in gradually. So I could > start out by storing shared_ptr's in the map's object list, making sure > they get free'd at the right time. Then I could add weak_ptr's to the > schedules code, which *might* fix the current problem, or at least expose > it. > On 11/6/18 1:00 AM, Marzo Junior wrote: > > Hi Jeff, > > That is basically it, yes; but let me rephrase your 3 points in a way that > may be helpful: > > At the top of any call chain, we want to start from either a weak_ptr and > turn it to a shared_ptr, or with a shared_ptr. Once we have a shared_ptr, > we can pass down raw (non-smart) pointers. Whenever we need to pass a > pointer outside of the call chain, we should pass a weak_ptr or a > shared_ptr; and this is where enable_shared_from_this is useful, as it > enables us to convert a pointer (which we know is valid due to the > shared_ptr at the top of the call chain) to a shared_ptr or to a weak_ptr. > > Does that sum up nicely your points? > > If so, yes, this will work perfectly and guarantee that we don't hold > references to dead objects. > > A few considerations: > > 1. For exception safety reasons, shared_ptr should be created using > make_shared, and unique_ptr with make_unique (c++14 only, but easily > emulated in c++11: we can literally just copy the code and it will work). > Using make_shared is slightly faster (it needs only one memory allocation), > and reduces the number of bare "new" in the codebase; it has the > disadvantage that the whole object memory will only be deallocated when the > last reference (weak or strong) goes away. > > 2. As a rule, shared_ptr, weak_ptr, and unique_ptr should not be > explicitly reset when leaving the scope/in destructors (this defeats their > purpose). The exception is when you have a chain of them (each one holding > the last/only reference to the next) and you want to guarantee that you > will not have a stack overflow. For Game_object, this is relevant for the > owning chunk/object. > > 3. We can remove a lot of cleanup code with judicial use of smart > pointers. For example, time-sensitive objects remove themselves from the > time queue upon deletion. If we make the time queue hold weak_ptr, try to > turn it to a smart_ptr before doing the callback, and ignore all objects > that no longer exist, we can remove that cleanup code. Also, the whole code > for notifying schedules that an object was deleted. > > After messing around with the code, I've come to a few realizations: >> >> 1. Just changing everything to shared_ptr<Game_object> isn't by itself >> going to solve our problem, which is that we store references to objects in >> schedules (and other places), but those objects might be deleted from the >> world. When this happens currently, it can result in memory corruption, >> because we free the objects' memory. So if the schedule moves or changes >> the object, it ends up writing over something else. So probably, >> schedules would store weak_ptr's to objects and query them before doing >> anything. The query would not only be to see if the object still exists, >> but that it is still in the world (or on an NPC). >> >> 2. There are only two actual owners of an object: The Map_chunk that >> contains it, or a Container_game_object (like a chest or NPC) that it is >> within. Those are probably the only places where we have to store a >> shared_ptr. All (or most) others should be weak_ptr's. >> > 3. If we inherit Game_object from std::enable_shared_from_this, then we >> can always get a shared or weak pointer from a 'raw' Game_object. So we >> don't have to modify all the code to use and pass shared_ptr's. (I'm not >> sure about this; but if it's true, we won't have as much of a performance >> hit, and this won't be all that difficult a project.) >> > > |
|
From: jeff <jef...@gm...> - 2018-11-08 23:51:31
|
:-) Maybe we should implement those too. On 11/8/18 2:52 PM, Dominik Reichardt wrote: > Just for laughs and because it fits. A 2014 interview with Bill > Randolph, lead programmer on Ultima 9: > > UC: And tying back to what you had said earlier, I imagine that if you > were already dealing with battling Windows for precious chunks of data > storage, that saving the state of this barrel — which I’ve now turned > from one object into about four, and then moved those four pieces > around — I can only imagine that the whole caching in/caching out was > just Hell on Earth. > > BR: Yes. Oh, I have a great story for you, now that you’ve reminded me > of this. > > One of the other things I worked on in the game was the hanging signs. > And I don’t know…let me call your attention, in Ultima 9, to those > hanging signs, because they’re awesome. They started out as…it was > just an example of something Richard wanted because it was > interactive. He wanted you to be able to tap a hanging sign and have > it swing, okay? And so I put in logic that was just a simple > oscillation…and we looked at that and thought: “that’s terrible.” So I > actually added physics to it; I added exponential decay. And then I > added a little bit of a yaw element to it. > > And then we added wind, so that when there were multiple signs in the > town, and the wind blew, they would all blow, and kick in, and swing. > And you could shoot an arrow into the sign, and it would react to the > arrow you shot; I don’t know if you ever tried that. But try it > sometime, shoot an arrow into a sign. > > Anyway, we had one of these signs that was swinging in the wind > (laughs) and it was just at the end of what we called the “fast area”, > which was the area cached in around you that updates, and the area > outside of that is cached out and saved to disk. Well, this sign swung > and crossed a boundary, and dropped out of the fast area…crunch!…saved > to disk. And the little controller that was running it crashed. > “Where’s my object?” So that was just one example of the kind of…oh my > gosh, this game was unbelievably complicated. > > > whole interview > http://ultimacodex.com/interviews/an-inertia-of-legend-an-interview-with-bill-randolph/ > >> On 7. Nov 2018, at 02:06, Jeff Freedman <jef...@gm... >> <mailto:jef...@gm...>> wrote: >> >> Yes, that's it. And I think it could be phased in gradually. So I >> could start out by storing shared_ptr's in the map's object list, >> making sure they get free'd at the right time. Then I could add >> weak_ptr's to the schedules code, which *might* fix the current >> problem, or at least expose it. >> >> On 11/6/18 1:00 AM, Marzo Junior wrote: >>> Hi Jeff, >>> >>> That is basically it, yes; but let me rephrase your 3 points in a >>> way that may be helpful: >>> >>> At the top of any call chain, we want to start from either a >>> weak_ptr and turn it to a shared_ptr, or with a shared_ptr. Once we >>> have a shared_ptr, we can pass down raw (non-smart) pointers. >>> Whenever we need to pass a pointer outside of the call chain, we >>> should pass a weak_ptr or a shared_ptr; and this is where >>> enable_shared_from_this is useful, as it enables us to convert a >>> pointer (which we know is valid due to the shared_ptr at the top of >>> the call chain) to a shared_ptr or to a weak_ptr. >>> >>> Does that sum up nicely your points? >>> >>> If so, yes, this will work perfectly and guarantee that we don't >>> hold references to dead objects. >>> >>> A few considerations: >>> >>> 1. For exception safety reasons, shared_ptr should be created using >>> make_shared, and unique_ptr with make_unique (c++14 only, but easily >>> emulated in c++11: we can literally just copy the code and it will >>> work). Using make_shared is slightly faster (it needs only one >>> memory allocation), and reduces the number of bare "new" in the >>> codebase; it has the disadvantage that the whole object memory will >>> only be deallocated when the last reference (weak or strong) goes away. >>> >>> 2. As a rule, shared_ptr, weak_ptr, and unique_ptr should not be >>> explicitly reset when leaving the scope/in destructors (this defeats >>> their purpose). The exception is when you have a chain of them (each >>> one holding the last/only reference to the next) and you want to >>> guarantee that you will not have a stack overflow. For Game_object, >>> this is relevant for the owning chunk/object. >>> >>> 3. We can remove a lot of cleanup code with judicial use of smart >>> pointers. For example, time-sensitive objects remove themselves from >>> the time queue upon deletion. If we make the time queue hold >>> weak_ptr, try to turn it to a smart_ptr before doing the callback, >>> and ignore all objects that no longer exist, we can remove that >>> cleanup code. Also, the whole code for notifying schedules that an >>> object was deleted. >>> >>> After messing around with the code, I've come to a few realizations: >>> >>> 1. Just changing everything to shared_ptr<Game_object> isn't by >>> itself going to solve our problem, which is that we store >>> references to objects in schedules (and other places), but those >>> objects might be deleted from the world. When this happens >>> currently, it can result in memory corruption, because we free >>> the objects' memory. So if the schedule moves or changes the >>> object, it ends up writing over something else. So probably, >>> schedules would store weak_ptr's to objects and query them >>> before doing anything. The query would not only be to see if the >>> object still exists, but that it is still in the world (or on an >>> NPC). >>> >>> 2. There are only two actual owners of an object: The >>> Map_chunk that contains it, or a Container_game_object (like a >>> chest or NPC) that it is within. Those are probably the only >>> places where we have to store a shared_ptr. All (or most) >>> others should be weak_ptr's. >>> >>> 3. If we inherit Game_object from std::enable_shared_from_this, >>> then we can always get a shared or weak pointer from a 'raw' >>> Game_object. So we don't have to modify all the code to use and >>> pass shared_ptr's. (I'm not sure about this; but if it's true, >>> we won't have as much of a performance hit, and this won't be >>> all that difficult a project.) >>> > |
|
From: Dominik R. <do...@re...> - 2018-11-08 22:52:55
|
Just for laughs and because it fits. A 2014 interview with Bill Randolph, lead programmer on Ultima 9: UC: And tying back to what you had said earlier, I imagine that if you were already dealing with battling Windows for precious chunks of data storage, that saving the state of this barrel — which I’ve now turned from one object into about four, and then moved those four pieces around — I can only imagine that the whole caching in/caching out was just Hell on Earth. BR: Yes. Oh, I have a great story for you, now that you’ve reminded me of this. One of the other things I worked on in the game was the hanging signs. And I don’t know…let me call your attention, in Ultima 9, to those hanging signs, because they’re awesome. They started out as…it was just an example of something Richard wanted because it was interactive. He wanted you to be able to tap a hanging sign and have it swing, okay? And so I put in logic that was just a simple oscillation…and we looked at that and thought: “that’s terrible.” So I actually added physics to it; I added exponential decay. And then I added a little bit of a yaw element to it. And then we added wind, so that when there were multiple signs in the town, and the wind blew, they would all blow, and kick in, and swing. And you could shoot an arrow into the sign, and it would react to the arrow you shot; I don’t know if you ever tried that. But try it sometime, shoot an arrow into a sign. Anyway, we had one of these signs that was swinging in the wind (laughs) and it was just at the end of what we called the “fast area”, which was the area cached in around you that updates, and the area outside of that is cached out and saved to disk. Well, this sign swung and crossed a boundary, and dropped out of the fast area…crunch!…saved to disk. And the little controller that was running it crashed. “Where’s my object?” So that was just one example of the kind of…oh my gosh, this game was unbelievably complicated. whole interview http://ultimacodex.com/interviews/an-inertia-of-legend-an-interview-with-bill-randolph/ > On 7. Nov 2018, at 02:06, Jeff Freedman <jef...@gm...> wrote: > > Yes, that's it. And I think it could be phased in gradually. So I could start out by storing shared_ptr's in the map's object list, making sure they get free'd at the right time. Then I could add weak_ptr's to the schedules code, which *might* fix the current problem, or at least expose it. > > On 11/6/18 1:00 AM, Marzo Junior wrote: > >> Hi Jeff, >> >> That is basically it, yes; but let me rephrase your 3 points in a way that may be helpful: >> >> At the top of any call chain, we want to start from either a weak_ptr and turn it to a shared_ptr, or with a shared_ptr. Once we have a shared_ptr, we can pass down raw (non-smart) pointers. Whenever we need to pass a pointer outside of the call chain, we should pass a weak_ptr or a shared_ptr; and this is where enable_shared_from_this is useful, as it enables us to convert a pointer (which we know is valid due to the shared_ptr at the top of the call chain) to a shared_ptr or to a weak_ptr. >> >> Does that sum up nicely your points? >> >> If so, yes, this will work perfectly and guarantee that we don't hold references to dead objects. >> >> A few considerations: >> >> 1. For exception safety reasons, shared_ptr should be created using make_shared, and unique_ptr with make_unique (c++14 only, but easily emulated in c++11: we can literally just copy the code and it will work). Using make_shared is slightly faster (it needs only one memory allocation), and reduces the number of bare "new" in the codebase; it has the disadvantage that the whole object memory will only be deallocated when the last reference (weak or strong) goes away. >> >> 2. As a rule, shared_ptr, weak_ptr, and unique_ptr should not be explicitly reset when leaving the scope/in destructors (this defeats their purpose). The exception is when you have a chain of them (each one holding the last/only reference to the next) and you want to guarantee that you will not have a stack overflow. For Game_object, this is relevant for the owning chunk/object. >> >> 3. We can remove a lot of cleanup code with judicial use of smart pointers. For example, time-sensitive objects remove themselves from the time queue upon deletion. If we make the time queue hold weak_ptr, try to turn it to a smart_ptr before doing the callback, and ignore all objects that no longer exist, we can remove that cleanup code. Also, the whole code for notifying schedules that an object was deleted. >> >>> After messing around with the code, I've come to a few realizations: >>> >>> 1. Just changing everything to shared_ptr<Game_object> isn't by itself going to solve our problem, which is that we store references to objects in schedules (and other places), but those objects might be deleted from the world. When this happens currently, it can result in memory corruption, because we free the objects' memory. So if the schedule moves or changes the object, it ends up writing over something else. So probably, schedules would store weak_ptr's to objects and query them before doing anything. The query would not only be to see if the object still exists, but that it is still in the world (or on an NPC). >>> >>> 2. There are only two actual owners of an object: The Map_chunk that contains it, or a Container_game_object (like a chest or NPC) that it is within. Those are probably the only places where we have to store a shared_ptr. All (or most) others should be weak_ptr's. >> >>> 3. If we inherit Game_object from std::enable_shared_from_this, then we can always get a shared or weak pointer from a 'raw' Game_object. So we don't have to modify all the code to use and pass shared_ptr's. (I'm not sure about this; but if it's true, we won't have as much of a performance hit, and this won't be all that difficult a project.) |
|
From: Jeff F. <jef...@gm...> - 2018-11-07 01:06:47
|
Yes, that's it. And I think it could be phased in gradually. So I could start out by storing shared_ptr's in the map's object list, making sure they get free'd at the right time. Then I could add weak_ptr's to the schedules code, which *might* fix the current problem, or at least expose it. On 11/6/18 1:00 AM, Marzo Junior wrote: > Hi Jeff, > > That is basically it, yes; but let me rephrase your 3 points in a way > that may be helpful: > > At the top of any call chain, we want to start from either a weak_ptr > and turn it to a shared_ptr, or with a shared_ptr. Once we have a > shared_ptr, we can pass down raw (non-smart) pointers. Whenever we > need to pass a pointer outside of the call chain, we should pass a > weak_ptr or a shared_ptr; and this is where enable_shared_from_this is > useful, as it enables us to convert a pointer (which we know is valid > due to the shared_ptr at the top of the call chain) to a shared_ptr or > to a weak_ptr. > > Does that sum up nicely your points? > > If so, yes, this will work perfectly and guarantee that we don't hold > references to dead objects. > > A few considerations: > > 1. For exception safety reasons, shared_ptr should be created using > make_shared, and unique_ptr with make_unique (c++14 only, but easily > emulated in c++11: we can literally just copy the code and it will > work). Using make_shared is slightly faster (it needs only one memory > allocation), and reduces the number of bare "new" in the codebase; it > has the disadvantage that the whole object memory will only be > deallocated when the last reference (weak or strong) goes away. > > 2. As a rule, shared_ptr, weak_ptr, and unique_ptr should not be > explicitly reset when leaving the scope/in destructors (this defeats > their purpose). The exception is when you have a chain of them (each > one holding the last/only reference to the next) and you want to > guarantee that you will not have a stack overflow. For Game_object, > this is relevant for the owning chunk/object. > > 3. We can remove a lot of cleanup code with judicial use of smart > pointers. For example, time-sensitive objects remove themselves from > the time queue upon deletion. If we make the time queue hold weak_ptr, > try to turn it to a smart_ptr before doing the callback, and ignore > all objects that no longer exist, we can remove that cleanup code. > Also, the whole code for notifying schedules that an object was deleted. > > After messing around with the code, I've come to a few realizations: > > 1. Just changing everything to shared_ptr<Game_object> isn't by > itself going to solve our problem, which is that we store > references to objects in schedules (and other places), but those > objects might be deleted from the world. When this happens > currently, it can result in memory corruption, because we free the > objects' memory. So if the schedule moves or changes the object, > it ends up writing over something else. So probably, schedules > would store weak_ptr's to objects and query them before doing > anything. The query would not only be to see if the object still > exists, but that it is still in the world (or on an NPC). > > 2. There are only two actual owners of an object: The Map_chunk > that contains it, or a Container_game_object (like a chest or NPC) > that it is within. Those are probably the only places where we > have to store a shared_ptr. All (or most) others should be > weak_ptr's. > > 3. If we inherit Game_object from std::enable_shared_from_this, > then we can always get a shared or weak pointer from a 'raw' > Game_object. So we don't have to modify all the code to use and > pass shared_ptr's. (I'm not sure about this; but if it's true, we > won't have as much of a performance hit, and this won't be all > that difficult a project.) > |
|
From: Marzo J. <ma...@gm...> - 2018-11-06 09:01:15
|
Hi Jeff, That is basically it, yes; but let me rephrase your 3 points in a way that may be helpful: At the top of any call chain, we want to start from either a weak_ptr and turn it to a shared_ptr, or with a shared_ptr. Once we have a shared_ptr, we can pass down raw (non-smart) pointers. Whenever we need to pass a pointer outside of the call chain, we should pass a weak_ptr or a shared_ptr; and this is where enable_shared_from_this is useful, as it enables us to convert a pointer (which we know is valid due to the shared_ptr at the top of the call chain) to a shared_ptr or to a weak_ptr. Does that sum up nicely your points? If so, yes, this will work perfectly and guarantee that we don't hold references to dead objects. A few considerations: 1. For exception safety reasons, shared_ptr should be created using make_shared, and unique_ptr with make_unique (c++14 only, but easily emulated in c++11: we can literally just copy the code and it will work). Using make_shared is slightly faster (it needs only one memory allocation), and reduces the number of bare "new" in the codebase; it has the disadvantage that the whole object memory will only be deallocated when the last reference (weak or strong) goes away. 2. As a rule, shared_ptr, weak_ptr, and unique_ptr should not be explicitly reset when leaving the scope/in destructors (this defeats their purpose). The exception is when you have a chain of them (each one holding the last/only reference to the next) and you want to guarantee that you will not have a stack overflow. For Game_object, this is relevant for the owning chunk/object. 3. We can remove a lot of cleanup code with judicial use of smart pointers. For example, time-sensitive objects remove themselves from the time queue upon deletion. If we make the time queue hold weak_ptr, try to turn it to a smart_ptr before doing the callback, and ignore all objects that no longer exist, we can remove that cleanup code. Also, the whole code for notifying schedules that an object was deleted. After messing around with the code, I've come to a few realizations: > > 1. Just changing everything to shared_ptr<Game_object> isn't by itself > going to solve our problem, which is that we store references to objects in > schedules (and other places), but those objects might be deleted from the > world. When this happens currently, it can result in memory corruption, > because we free the objects' memory. So if the schedule moves or changes > the object, it ends up writing over something else. So probably, > schedules would store weak_ptr's to objects and query them before doing > anything. The query would not only be to see if the object still exists, > but that it is still in the world (or on an NPC). > > 2. There are only two actual owners of an object: The Map_chunk that > contains it, or a Container_game_object (like a chest or NPC) that it is > within. Those are probably the only places where we have to store a > shared_ptr. All (or most) others should be weak_ptr's. > 3. If we inherit Game_object from std::enable_shared_from_this, then we > can always get a shared or weak pointer from a 'raw' Game_object. So we > don't have to modify all the code to use and pass shared_ptr's. (I'm not > sure about this; but if it's true, we won't have as much of a performance > hit, and this won't be all that difficult a project.) > |
|
From: jeff <jef...@gm...> - 2018-11-06 05:38:10
|
After messing around with the code, I've come to a few realizations: 1. Just changing everything to shared_ptr<Game_object> isn't by itself going to solve our problem, which is that we store references to objects in schedules (and other places), but those objects might be deleted from the world. When this happens currently, it can result in memory corruption, because we free the objects' memory. So if the schedule moves or changes the object, it ends up writing over something else. So probably, schedules would store weak_ptr's to objects and query them before doing anything. The query would not only be to see if the object still exists, but that it is still in the world (or on an NPC). 2. There are only two actual owners of an object: The Map_chunk that contains it, or a Container_game_object (like a chest or NPC) that it is within. Those are probably the only places where we have to store a shared_ptr. All (or most) others should be weak_ptr's. 3. If we inherit Game_object from std::enable_shared_from_this, then we can always get a shared or weak pointer from a 'raw' Game_object. So we don't have to modify all the code to use and pass shared_ptr's. (I'm not sure about this; but if it's true, we won't have as much of a performance hit, and this won't be all that difficult a project.) On 11/3/18 2:51 PM, Marzo Junior wrote: > Hi Jeff, > > A few years ago (7 or so, if memory serves), I had suggested just > that. Some concerns were raised about performance; I started a private > branch to check out if it would be to slow. To give you an idea, I was > about a 3rd of the way done (and some thousands of lines in changes), > and Exult was still not compiling; it is a lot of work. This branch is > now hopelessly out of date, and it would be easier to recreate > everything from scratch. > > One big issue I came across is that objects in each chunk are in a > circular linked list; we would have to manage this to avoid leaking > objects. An interesting thing I discovered (and fixed) some time ago > is that this list was managed incorrectly (since when it was written, > in fact), and it was leaking most objects when a chunk got deleted. > And just changing the code to use smart pointers would have made no > difference. > > I am all for using smart pointers. There is a performance hit from > using shared_ptr/weak_ptr*, but it is very small; there is no > performance penalty from using unique_ptr, but it does not fit our > needs. Also, given current code, we would need to be able to obtain a > shared_ptr from a pointer; meaning we would need to use > enable_shared_from_this. > > However, Exult is still in c++03, meaning we would not be able to use > the standard ones from c++11 since Exult is still c++03. I am also > interested in updating to more modern c++, particularly since > Microsoft compilers no longer suck in terms of standards support (and > are, for once, ahead of GCC and clang). Given recent advances in > compilers, even jumping to c++17† would be possible. > > The major issues are some ancient platforms we still support which > only have very ancient versions of GCC and are no longer updated. I > have done some work on dropping them, but there is still PPC. If we > were to update, I would suggest skipping to c++14 directly. > > Also, I would be in favor of using not just shared_ptr, weak_ptr, and > unique_ptr whenever possible, but also of using not_null and owner_ptr > from the Guidelines Support Library when, for whatever reason, smart > pointers can't be used. The former cannot be a null pointer, and > throws an exception when it happens (or does not compile, if the > compiler can determine this during compilation); the latter is just > annotation on the type, so that programmers and static analyzers can > see who is responsible for deleting the pointer. > > * Some data: http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf > > † For MS compiler; GCC and clang are still lacking in there parallel > algorithms (but this is expected to change, since Intel is donating > their implementation of them)‡. > > ‡ Why, yes, I am exceedingly well informed in modern c++, and eagerly > awaiting for c++20. Why do you ask? > > On Sat, 3 Nov 2018, 21:19 jeff, <jef...@gm... > <mailto:jef...@gm...>> wrote: > > I just started reading about smart pointers in C++ (being behind the > times), and wondering if using 'std::shared_ptr' for our game objects > might make our code more robust. Have any of you used this? Is > there > much of a performance hit? It looks like it could simplify a lot > of our > code where we're trying to keep track of which objects are still > alive. > |
|
From: Dominik R. <do...@re...> - 2018-11-04 22:45:42
|
(sent again as it didn’t seem to propagate to the ML) Heya Jeff and Marzo, As much as I’d like Exult to be better, the start from scratch sounds to me like dreadful doom. We just don’t have any man power anymore :( We’ve come so close to be able to do a new release but the way no one has time anymore is really not helping. So IMO we need to put another bandaid on the code before even thinking of starting from scratch. As for c++1X, I do not see any need to maintain compatibility with PPC. It was nice while it lasted but the last PowerPC Macs saw the light in 2005. They are simply not worth supporting anymore. Already Exult for PowerPC is not using SDL2 because that is no longer compatible… So, another IMO, let Marzo gut Exult’s code for ancient ancient platforms and maybe gut SDL 1.2x as well (all with a big tag to mark the cutoff point). Take care Dom > On 4. Nov 2018, at 19:29, Marzo Junior <ma...@gm...> wrote: > > Regarding moving to a new c++ standard: I just became aware of this project: https://github.com/neobrain/cftf > > Basically, it serves as a source preprocessing step which converts c++14 or c++17 code to c++11 code. Since GCC 4.8.1 already had full c++11 support, this could be a viable way to keep support for older platforms which have at least this version of GCC. > > On Sun, 4 Nov 2018, 12:46 Marzo Junior, <ma...@gm...> wrote: > >> This should have gone to the list (dumb Gmail): >> >> ---------- Forwarded message --------- >> From: Marzo Junior <ma...@gm...> >> Date: Sun, 4 Nov 2018, 09:33 >> Subject: Re: [Exult-general] The never-ending memory bugs >> To: jeff <jef...@gm...> >> >>> I was worried about compatibility on the various platforms. However, when I compile Exult, I see 'g++ -std=c++11'. Are we configured to use this, or is it something to do with my machine, Ubuntu 16.04? >> >> I modified [configure.ac](http://configure.ac/) to use c++11 when available (and give warnings with code that is not backwards compatible). Currently, Windows (MSVC and MinGW) use old compilers, but can be upgraded, pocket PC uses an old compiler and cannot be upgraded, and so does WinCE (but I doubt it still works). >> >> Windows had the additional issue of GTK and Windows 9x: less ancient releases of GTK on Windows dropped support for pre-WinXP. When we talked about this on IRC, it was decided that we should do one last release before dropping 9x support (and upgrade the compiler on Windows). >> >> This upgrade would be simple on MinGW (upgrade compiler, add flag for more modern standard), slightly harder on MSVC (upgrade MSVC version, upgrade project, add flag for new standard). >> >>> From my little bit of reading, I'd guess that an Object_list would still have a destructor. But instead of doing a 'delete' on each object, we would do a 'reset()' on it. Would that solve the problem of having a circular list? Otherwise, the list could be redesigned to not be circular. >> >> That is correct: even with smart points we still need to go through these lists and release the objects; with a long enough list the is the risk of a stack overflow of we do it differently. >> >>> I'm also a little unclear on using 'weak_ptr', and think it wouldn't be used much in our code. But possibly in schedules, which reference objects that could possibly be deleted from the world. >> >> Schedules and usecode static variables, most likely. >> >>> I'd be most likely to start this from scratch. But it does look like a LOT of work. >> >> Dominus, wjp, and me discussed starting from scratch on IRC some time ago. There are several subsystems which I would really like to redo entirely (file handling, text handling, game handling, and intro handling immediately spring to mind, but I have a longer list). Back when we talked about this, I was reading this book: http://gameprogrammingpatterns.com/ (there is a physical release, but the author gives a web version away for free on this website). >> >> We could take some ideas from it, if we do indeed start from scratch. |
|
From: Dominik R. <do...@re...> - 2018-11-04 22:40:35
|
Seems this also never made it to the list. > On 4. Jun 2018, at 10:01, Dominik Reichardt <do...@us...> wrote: > > Hi all, > > I'm going to host an Event for Ultima fans next year, 2019. It's going to be in southwest Germany, between Stuttgart and Heidelberg in an old castle. > Plans are to get Richard Garriott to attend. Because it is the weekend before the Gamescom in Cologne, the chances are actually not that bad. But nothing can be promised! > > A little bit more information at http://eurodragons.com > > August 23. - 25. on Castle Stocksberg! > > I would love to see some Exult devs there!!! > > Cheers > Dominik |
|
From: Marzo J. <ma...@gm...> - 2018-11-04 18:29:27
|
Regarding moving to a new c++ standard: I just became aware of this project: https://github.com/neobrain/cftf Basically, it serves as a source preprocessing step which converts c++14 or c++17 code to c++11 code. Since GCC 4.8.1 already had full c++11 support, this could be a viable way to keep support for older platforms which have at least this version of GCC. On Sun, 4 Nov 2018, 12:46 Marzo Junior, <ma...@gm...> wrote: > This should have gone to the list (dumb Gmail): > > ---------- Forwarded message --------- > From: Marzo Junior <ma...@gm...> > Date: Sun, 4 Nov 2018, 09:33 > Subject: Re: [Exult-general] The never-ending memory bugs > To: jeff <jef...@gm...> > > I was worried about compatibility on the various platforms. However, when >> I compile Exult, I see 'g++ -std=c++11'. Are we configured to use this, or >> is it something to do with my machine, Ubuntu 16.04? >> > I modified configure.ac to use c++11 when available (and give warnings > with code that is not backwards compatible). Currently, Windows (MSVC and > MinGW) use old compilers, but can be upgraded, pocket PC uses an old > compiler and cannot be upgraded, and so does WinCE (but I doubt it still > works). > > Windows had the additional issue of GTK and Windows 9x: less ancient > releases of GTK on Windows dropped support for pre-WinXP. When we talked > about this on IRC, it was decided that we should do one last release before > dropping 9x support (and upgrade the compiler on Windows). > > This upgrade would be simple on MinGW (upgrade compiler, add flag for more > modern standard), slightly harder on MSVC (upgrade MSVC version, upgrade > project, add flag for new standard). > > From my little bit of reading, I'd guess that an Object_list would still >> have a destructor. But instead of doing a 'delete' on each object, we >> would do a 'reset()' on it. Would that solve the problem of having a >> circular list? Otherwise, the list could be redesigned to not be circular. >> > That is correct: even with smart points we still need to go through these > lists and release the objects; with a long enough list the is the risk of a > stack overflow of we do it differently. > > I'm also a little unclear on using 'weak_ptr', and think it wouldn't be >> used much in our code. But possibly in schedules, which reference objects >> that could possibly be deleted from the world. >> > Schedules and usecode static variables, most likely. > >> I'd be most likely to start this from scratch. But it does look like a >> LOT of work. >> > Dominus, wjp, and me discussed starting from scratch on IRC some time ago. > There are several subsystems which I would really like to redo entirely > (file handling, text handling, game handling, and intro handling > immediately spring to mind, but I have a longer list). Back when we talked > about this, I was reading this book: http://gameprogrammingpatterns.com/ > (there is a physical release, but the author gives a web version away for > free on this website). > > We could take some ideas from it, if we do indeed start from scratch. > |
|
From: Marzo J. <ma...@gm...> - 2018-11-04 11:46:50
|
This should have gone to the list (dumb Gmail): ---------- Forwarded message --------- From: Marzo Junior <ma...@gm...> Date: Sun, 4 Nov 2018, 09:33 Subject: Re: [Exult-general] The never-ending memory bugs To: jeff <jef...@gm...> I was worried about compatibility on the various platforms. However, when > I compile Exult, I see 'g++ -std=c++11'. Are we configured to use this, or > is it something to do with my machine, Ubuntu 16.04? > I modified configure.ac to use c++11 when available (and give warnings with code that is not backwards compatible). Currently, Windows (MSVC and MinGW) use old compilers, but can be upgraded, pocket PC uses an old compiler and cannot be upgraded, and so does WinCE (but I doubt it still works). Windows had the additional issue of GTK and Windows 9x: less ancient releases of GTK on Windows dropped support for pre-WinXP. When we talked about this on IRC, it was decided that we should do one last release before dropping 9x support (and upgrade the compiler on Windows). This upgrade would be simple on MinGW (upgrade compiler, add flag for more modern standard), slightly harder on MSVC (upgrade MSVC version, upgrade project, add flag for new standard). >From my little bit of reading, I'd guess that an Object_list would still > have a destructor. But instead of doing a 'delete' on each object, we > would do a 'reset()' on it. Would that solve the problem of having a > circular list? Otherwise, the list could be redesigned to not be circular. > That is correct: even with smart points we still need to go through these lists and release the objects; with a long enough list the is the risk of a stack overflow of we do it differently. I'm also a little unclear on using 'weak_ptr', and think it wouldn't be > used much in our code. But possibly in schedules, which reference objects > that could possibly be deleted from the world. > Schedules and usecode static variables, most likely. > I'd be most likely to start this from scratch. But it does look like a > LOT of work. > Dominus, wjp, and me discussed starting from scratch on IRC some time ago. There are several subsystems which I would really like to redo entirely (file handling, text handling, game handling, and intro handling immediately spring to mind, but I have a longer list). Back when we talked about this, I was reading this book: http://gameprogrammingpatterns.com/ (there is a physical release, but the author gives a web version away for free on this website). We could take some ideas from it, if we do indeed start from scratch. |
|
From: jeff <jef...@gm...> - 2018-11-03 22:32:04
|
I was worried about compatibility on the various platforms. However, when I compile Exult, I see 'g++ -std=c++11'. Are we configured to use this, or is it something to do with my machine, Ubuntu 16.04? From my little bit of reading, I'd guess that an Object_list would still have a destructor. But instead of doing a 'delete' on each object, we would do a 'reset()' on it. Would that solve the problem of having a circular list? Otherwise, the list could be redesigned to not be circular. I'm also a little unclear on using 'weak_ptr', and think it wouldn't be used much in our code. But possibly in schedules, which reference objects that could possibly be deleted from the world. I'd be most likely to start this from scratch. But it does look like a LOT of work. On 11/3/18 2:51 PM, Marzo Junior wrote: > Hi Jeff, > > A few years ago (7 or so, if memory serves), I had suggested just > that. Some concerns were raised about performance; I started a private > branch to check out if it would be to slow. To give you an idea, I was > about a 3rd of the way done (and some thousands of lines in changes), > and Exult was still not compiling; it is a lot of work. This branch is > now hopelessly out of date, and it would be easier to recreate > everything from scratch. > > One big issue I came across is that objects in each chunk are in a > circular linked list; we would have to manage this to avoid leaking > objects. An interesting thing I discovered (and fixed) some time ago > is that this list was managed incorrectly (since when it was written, > in fact), and it was leaking most objects when a chunk got deleted. > And just changing the code to use smart pointers would have made no > difference. > > I am all for using smart pointers. There is a performance hit from > using shared_ptr/weak_ptr*, but it is very small; there is no > performance penalty from using unique_ptr, but it does not fit our > needs. Also, given current code, we would need to be able to obtain a > shared_ptr from a pointer; meaning we would need to use > enable_shared_from_this. > > However, Exult is still in c++03, meaning we would not be able to use > the standard ones from c++11 since Exult is still c++03. I am also > interested in updating to more modern c++, particularly since > Microsoft compilers no longer suck in terms of standards support (and > are, for once, ahead of GCC and clang). Given recent advances in > compilers, even jumping to c++17† would be possible. > > The major issues are some ancient platforms we still support which > only have very ancient versions of GCC and are no longer updated. I > have done some work on dropping them, but there is still PPC. If we > were to update, I would suggest skipping to c++14 directly. > > Also, I would be in favor of using not just shared_ptr, weak_ptr, and > unique_ptr whenever possible, but also of using not_null and owner_ptr > from the Guidelines Support Library when, for whatever reason, smart > pointers can't be used. The former cannot be a null pointer, and > throws an exception when it happens (or does not compile, if the > compiler can determine this during compilation); the latter is just > annotation on the type, so that programmers and static analyzers can > see who is responsible for deleting the pointer. > > * Some data: http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf > > † For MS compiler; GCC and clang are still lacking in there parallel > algorithms (but this is expected to change, since Intel is donating > their implementation of them)‡. > > ‡ Why, yes, I am exceedingly well informed in modern c++, and eagerly > awaiting for c++20. Why do you ask? > > On Sat, 3 Nov 2018, 21:19 jeff, <jef...@gm... > <mailto:jef...@gm...>> wrote: > > I just started reading about smart pointers in C++ (being behind the > times), and wondering if using 'std::shared_ptr' for our game objects > might make our code more robust. Have any of you used this? Is > there > much of a performance hit? It looks like it could simplify a lot > of our > code where we're trying to keep track of which objects are still > alive. > |
|
From: Marzo J. <ma...@gm...> - 2018-11-03 21:52:11
|
Hi Jeff, A few years ago (7 or so, if memory serves), I had suggested just that. Some concerns were raised about performance; I started a private branch to check out if it would be to slow. To give you an idea, I was about a 3rd of the way done (and some thousands of lines in changes), and Exult was still not compiling; it is a lot of work. This branch is now hopelessly out of date, and it would be easier to recreate everything from scratch. One big issue I came across is that objects in each chunk are in a circular linked list; we would have to manage this to avoid leaking objects. An interesting thing I discovered (and fixed) some time ago is that this list was managed incorrectly (since when it was written, in fact), and it was leaking most objects when a chunk got deleted. And just changing the code to use smart pointers would have made no difference. I am all for using smart pointers. There is a performance hit from using shared_ptr/weak_ptr*, but it is very small; there is no performance penalty from using unique_ptr, but it does not fit our needs. Also, given current code, we would need to be able to obtain a shared_ptr from a pointer; meaning we would need to use enable_shared_from_this. However, Exult is still in c++03, meaning we would not be able to use the standard ones from c++11 since Exult is still c++03. I am also interested in updating to more modern c++, particularly since Microsoft compilers no longer suck in terms of standards support (and are, for once, ahead of GCC and clang). Given recent advances in compilers, even jumping to c++17† would be possible. The major issues are some ancient platforms we still support which only have very ancient versions of GCC and are no longer updated. I have done some work on dropping them, but there is still PPC. If we were to update, I would suggest skipping to c++14 directly. Also, I would be in favor of using not just shared_ptr, weak_ptr, and unique_ptr whenever possible, but also of using not_null and owner_ptr from the Guidelines Support Library when, for whatever reason, smart pointers can't be used. The former cannot be a null pointer, and throws an exception when it happens (or does not compile, if the compiler can determine this during compilation); the latter is just annotation on the type, so that programmers and static analyzers can see who is responsible for deleting the pointer. * Some data: http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf † For MS compiler; GCC and clang are still lacking in there parallel algorithms (but this is expected to change, since Intel is donating their implementation of them)‡. ‡ Why, yes, I am exceedingly well informed in modern c++, and eagerly awaiting for c++20. Why do you ask? On Sat, 3 Nov 2018, 21:19 jeff, <jef...@gm...> wrote: > I just started reading about smart pointers in C++ (being behind the > times), and wondering if using 'std::shared_ptr' for our game objects > might make our code more robust. Have any of you used this? Is there > much of a performance hit? It looks like it could simplify a lot of our > code where we're trying to keep track of which objects are still alive. > |
|
From: jeff <jef...@gm...> - 2018-11-03 20:19:24
|
I just started reading about smart pointers in C++ (being behind the times), and wondering if using 'std::shared_ptr' for our game objects might make our code more robust. Have any of you used this? Is there much of a performance hit? It looks like it could simplify a lot of our code where we're trying to keep track of which objects are still alive. |
492 messages has been excluded from this view by a project administrator.
