|
Members in Shoutbox
None.
Shoutbox Search
Shoutbox Commands
/w [name] > Whisper
/r > Reply to last whisper /me > Marks as action Shoutbox Information
Moderators may delete any and all shouts at will.
|
Global Shoutbox
Please log in to shout.
[2016-4-19. : 8:05 am]  Clokr_ -- It gave a compilation error which I suspect it wasn't supposed to but was C++-standard-compliant[2016-4-19. : 8:05 am] Neiv -- And hey, soon it's going to be C++17 anyways, you don't even need to bother with C++11  [2016-4-19. : 8:02 am] Neiv -- Arguably a lot of that is only relevant for compiler developers as well[2016-4-19. : 8:01 am] Neiv -- (And then 50% of what it says doesn't apply to my pc which has AMD processor <.<)[2016-4-19. : 8:00 am] Neiv -- Oh, it's only 800 pages. That's easy http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf[2016-4-19. : 7:59 am] Clokr_ -- Oh if you find nice references let me know, I'm also interested in this kind of stuff and haven't found a good read[2016-4-19. : 7:58 am] Neiv -- I've been meaning read that several-thousand page Intel optimization manual someday  That could have some recommendations[2016-4-19. : 7:56 am] Neiv -- Also, to some extent it has to work with bw's original behaviour, which uses linked lists[2016-4-19. : 7:55 am] Neiv -- I've generally considered it not be *that* important, as the unit objects are ~350 bytes in size and there aren't that many predictable access patterns[2016-4-19. : 7:55 am] Clokr_ -- Check this out: http://gamedev.stackexchange.com/questions/33888/what-is-the-most-efficient-container-to-store-dynamic-game-objects-in[2016-4-19. : 7:53 am] Clokr_ -- I learned this recently, got a 100x performance boost in a simple program replacing an object list with an object pool[2016-4-19. : 7:52 am] Clokr_ -- But the problem is not allocation, it's accessing the memory with this scheme[2016-4-19. : 7:51 am] Neiv -- Yup, I've considered of pooling the objects for performance, but the allocation has not been that slow so far[2016-4-19. : 7:49 am] Neiv -- I just hooked the code which originally took an empty entry from an array and replaced it with allocation of a single object[2016-4-19. : 7:48 am] Clokr_ -- How did you allocate the new memory? Did you use a large memory pool or just lot of allocated arrays?[2016-4-19. : 7:47 am] Clokr_ -- They work extraordinarly well at the default amount though. SC runs pretty fast on very old computers.[2016-4-19. : 7:46 am] Neiv -- Some of the Blizzard's algorithms don't work that well at larger object amounts D:[2016-4-19. : 7:45 am] Neiv -- Well, bullet limit is only a day-or-two thing and it's the most useful imo[2016-4-19. : 7:44 am] Neiv -- Honestly, if I had knewn how many things there had to be changed, I wouldn't have even tried [2016-4-19. : 7:42 am] Clokr_ -- Btw Neiv, had a look at your hack to increase the limits of everything. Pretty amazing stuff. A lot of work too though.[2016-4-19. : 7:40 am] Neiv -- It's easier to support multiple versions as well when you understand what's happening [2016-4-19. : 7:37 am] Clokr_ -- That's what I have in mind. Again there's a patch around the corner! [2016-4-19. : 7:35 am]  O)FaRTy1billion[MM] -- one big unified array/struct would be cool, it'd be that much easier if we supported different SC versions [2016-4-19. : 7:32 am] O)FaRTy1billion[MM] -- Now it's { 0, 0, {0x004D5E12 +1, 0x004D6351 +1, 0}}, which is better I guess? The code will be clearer because it's calc = dats[IMAGES_DAT].newEntries * img_consts[i].factor + img_consts[i].add instead of thing * img_consts[i] + img_consts[i+1] xD[2016-4-19. : 7:29 am] O)FaRTy1billion[MM] -- anyway, once again I should've been in bed hours ago ;o[2016-4-19. : 7:28 am] O)FaRTy1billion[MM] -- I changed that one to struct{ signed int factor; signed int add; unsigned int ptr[20]; } img_consts[] though[2016-4-19. : 7:27 am] O)FaRTy1billion[MM] -- that might be good, except the problem is having to copy+paste that hundreds of times for every address [2016-4-19. : 7:25 am] Clokr_ -- That way you don't need to enter everything but you have an unified setting to work with and the data will be clear[2016-4-19. : 7:25 am] Clokr_ -- If you don't want to be redundant you can add flags in the whattodo member which mean: copy data from the last entry which didn't have this flag set[2016-4-19. : 7:24 am] Clokr_ -- I would still consider having just one struct of the type: unsigned int ptr, int whattodo, union{ struct data1 {...}; struct data2 {...}; ... }[2016-4-19. : 7:22 am] O)FaRTy1billion[MM] -- Clokr_Clokr_ shouted: Clarity > redundancy ya, but some of these that I haven't done yet get crazy, like I mentioned with the units.dat [2016-4-19. : 7:22 am] O)FaRTy1billion[MM] -- Clokr_Clokr_ shouted: ptr[999] ? I could do that, but I'd probably do like [20][2016-4-19. : 7:20 am] O)FaRTy1billion[MM] -- o, except I don't know how to have the ptr one be a variable sized array ;o[2016-4-19. : 7:19 am] O)FaRTy1billion[MM] -- it would be, I was thinking about that since I already have a bunch like it that are in a struct[2016-4-19. : 7:18 am] Neiv -- Having img_consts be a struct { factor, add, ptr } would be clearer though? If you don't mind having each patch there in a separate line [2016-4-19. : 7:18 am] Clokr_ -- It's still really messy, because you have here the pointers that you just replace, there the pointers where you have to inject assembly, etc[2016-4-19. : 7:17 am] O)FaRTy1billion[MM] -- and yes, less code. I can just do a nested loop instead of a copy of the loop for each array[2016-4-19. : 7:16 am] O)FaRTy1billion[MM] -- eh, I started with more arrays but then was like I don't want 1000 arrays[2016-4-19. : 7:16 am] Neiv -- I would have likely used multiple separate arrays instead of using zeroes to separate lists, but that's going to require more patching code[2016-4-19. : 7:15 am] O)FaRTy1billion[MM] -- I should just dump them in a seperate file so the actual arrays aren't immediately visible. |
Members Online: 
IskatuMesk, Dem0n
IskatuMesk, Dem0n