Dec 13 2015, 10:28 am
In response to Bl4ck Adam
|
|
10/10
|
In response to MagicMountain
|
|
Now if only we can get some raycast lighting going on, then we'd have something super awesome.
|
In response to Rushnut
|
|
Rushnut wrote:
That looks fantastic, it's really wonderful to see the SS13 community integrating with this thread, we'd love to see more of you! Have to agree. It's good to see you (MM) and a few others from SS13 interacting with the main site on a regular basis. It seems like it just used to be an occasional bitch session from one side or the other, but the mostly civil and intelligent discourse over the last year or two has been much more productive. I think you guys have helped push LummoxJR and the engine quite a bit. Those screenshots look pretty damn good too. Congrats on the update. |
In response to Nadrew
|
|
Nadrew wrote:
Now you guys just need to box that lighting stuff up into a library for the masses. Please! +1 |
In response to Exentriks Gaming
|
|
Exentriks Gaming wrote:
Nadrew wrote: +1 |
Since I won't be taking my finals, I figured I'd work on my BigInt library again. I think I have multiplication functioning now, though I want to try and work out some ways to speed it up as it's still a little slow. This is the profiler output from multiplying two 400 hexadecimal digit (approximately 480 decimal digit) numbers
/* and the actual output 0x638b1476614a373b6700b9dd2de35c032831cdc53908ab410642e41d0dc081425620b736434ae72741e0146847564bd51b47c104446c5b7671240d65170c2925e8230e24605ecc4081bcdeb252b46b7a57179c7b6945c3e5736d98225778a708d5ea1bac58a2116e8dc90a29ec17923274d938d3d8142ed44db9b51eac0184cc7735256865d6e7e2e96be599c72838c8b3d116c90677ac18eb9574244840a1238e3cd3ae78bd9ca44daa5ca2907c5d054c204eb1eb6bba6a1c353e43829eca19a116d9d5e13910b9 And this is for computing 150!
/* with the output being 0x96! = 0x01d07da7ecb62cbddc2a166afb4cb7ed3175b5eb8e806e18cb2b4f4be3bbe2e3dc8207bf84713210a5db6d998a9ccff80c548cfe68ad9ca5e8e3945a223632785ec7de448c0724a0699433ff5aea1297e14dd8d12a5b851fb7c19284000000000000000000000000000000000000 This is quite a significant speedup (about a 78% increase in speed). With my old method, computing 150! had a profiler output of
/* I have some more ideas of how to speed it up, courtesy of Donald Knuth, but I'll have to think a little bit on how exactly that should be implemented. |
In response to Nadrew
|
|
Nadrew wrote:
Now you guys just need to box that lighting stuff up into a library for the masses. |
In response to Nadrew
|
|
Nadrew wrote:
Now you guys just need to box that lighting stuff up into a library for the masses. I imagine it's a layer of objs where someone who can do much better math than me dynamically sets the icon_state to a gradient based off its neighbours, then sets to BLEND_MULTIPLY and just changes their RGB at runtime I'd love to see it also. |
In response to Bl4ck Adam
|
|
Bl4ck Adam wrote:
Panda suit! |
In response to GreatPirateEra
|
|
GreatPirateEra wrote:
Nadrew wrote: |
On an unrelated note, the occasionally-inverse correlation between code length and code efficiency is somewhat amusing, as it's unexpected. I mean, there's no hard and fast rule, but it still shows up a lot. As an example, this is the Multiplication method for this library as it currently stands.
pif_BigInt/proc It's more than twice as long as the previous approach (and if I can figure out how to speed it up to be more efficient, it'll be longer still), yet it seems to be about 75% faster than the old code. |
In response to Popisfizzy
|
|
I like this.
|
In response to Bravo1
|
|
I would probably like it to. If i understood what it was.
|
In response to Ghost of ET
|
|
Allows for very complicated math in order to get very precise results without Byond shitting itself in the process.
|
In response to Bravo1
|
|
Pft when would you ever use complicated math in programming video games xD?
Don't answer that... |
Okay, what Bravo said isn't entirely true, it's not that it allows complicated math, BYOND does that by itself, rather it allows ACCURATE math, when you do complicated math.
|
In response to Ghost of ET
|
|
Ghost of ET wrote:
I would probably like it to. If i understood what it was. It's a BigInt library, and while that ("big integer") is technically correct description of it, a more-precise name would be "arbitrary precision integer arithmetic". To be a bit clearer, BYOND has a 16-bit word length, so you can only work with integers between that fit in that word length. BYOND does some fiddly stuff with conversion to floats on the fly in the background, so it's hard to pin down exactly, but it's probably something like only being 'reliable' between -32,768 and 65,535. If BYOND had a strict int type that was 16 bits, then it would be between -32,768 and 32,768, and once you go outside that range it would roll over. What this library does (will do, whatever) is allow you to go arbitrarily beyond that range. Once you would normally roll over, it will just allocate more space. Thus, the only effective limit is how much memory can be allocated. In principle, you would also have to worry about speed, as at a certain point you will experience slowdowns due to the expense of computing these BigInts. In practice I don't see that being much of an issue for most people. E.g., this can compute the product of two ~400 hexadecimal digit numbers in less of a third of a second, and those numbers are on the order of 10480, so very, very massive. |
In response to Popisfizzy
|
|
Mostly correct, but the number is 2.1b with 15 bits (Technically 16, but strict.)
|
In response to Rushnut
|
|
Rushnut wrote:
Mostly correct, but the number is 2.1b with 15 bits I'm not sure what 2.1b is supposed to be here. |
In response to Popisfizzy
|
|
You lost me at 16-bit word length.
|