SHOW ME WHAT YOU GOT. [Show off your project!]

Page: 1 2 3 ... 107 108 109 110 111 ... 349 350 351
Dec 13 2015, 10:09 pm
2.1 billion.
Dec 13 2015, 10:12 pm
In response to Ghost of ET
Ghost of ET wrote:
You lost me at 16-bit word length.

A standard byte is 8 bits. A word is the number of bytes used by a given system. E.g., most processors nowadays use 32 bits as their 'standard unit' for processing purposes, so they have 4 byte words. DM uses two bytes, so it has a 16 bit word length.

If you aren't sure what a byte is, or what bits do, then this topic is way over your head.
Dec 13 2015, 10:14 pm
In response to Lavenblade
Lavenblade wrote:
2.1 billion.

That was what I first though, but 16 bit can absolutely not store 2.1 billion as an integer. Its hex value is 0x4E3B29200, which is would require three bytes words. If that's the case, then perhaps Rushnut is confusing integer representation with floating point representation.
Dec 13 2015, 10:15 pm
In response to Popisfizzy
I probably wouldnt have even bothered asking a question if i didnt know what a byte or a bit was xD.
Dec 13 2015, 10:41 pm
In response to Popisfizzy
Popisfizzy wrote:
If that's the case, then perhaps Rushnut is confusing integer representation with floating point representation.

This is entirely what I'm doing! But BYOND converts all standard integers into floats, if I'm not mistaken, due to how the engine handles it.

I might be completely talking out my arse though, I know for a fact if you go into DM and type out var/avar = 32465435623452345 it'll hard cap out at 2.1b. If at runtime you modify it above that number, it starts to vastly lose accuracy.

Dec 13 2015, 10:58 pm
In response to Bravo1
Bravo1 wrote:
Exentriks Gaming wrote:
Nadrew wrote:
Now you guys just need to box that lighting stuff up into a library for the masses.

Please! +1

+1

It's not my code so it's not my choice but I'm sure Tobba will release it at some point.

To be perfectly honest I barely understand how it functions, all I know is it uses the new 500 variables for color and blend modes and the 509 stuff for matrix color transforms.
Dec 13 2015, 11:03 pm
In response to Rushnut
I'm fairly sure what's happening is that BYOND is converting to a float on the fly as needed, though Lummox could possibly clarify. My reasoning for this is two fold:
  1. Negative integers are stored as two's complement (e.g., examining the bits of 0xFFFF and -1 show they have the same representation). Two's complement is not used in the mantissa of IEEE floating point numbers.
  2. Integers representable as 16 bits have the format you would expect when examining their bits. This is not true of floating point numbers. E.g., in IEEE single-precision floating point format, 1 is represented as 0x3F80000 rather than 0x0001.
Dec 14 2015, 7:38 am
Screenshotting lighting-related pictures turns out to be really iffy with most tools by the way; most seem to mess up the gamma somehow. Here's the same area from a page back with BYONDs own screenshot tool:
Dec 14 2015, 8:55 am
In response to Tobba
That still looks pretty darn nice.
Dec 14 2015, 12:05 pm


Path of Exile has captured my soul once more, but I'm still working on the game.

Here's the mugshot for the main character.

Dec 14 2015, 12:38 pm
Dec 14 2015, 12:42 pm
SENPAI: REQUESTING NOTICE OF THIS UNIT.
Dec 14 2015, 12:47 pm
Dec 14 2015, 5:32 pm
Just started my annual December project a couple days back and ended up finishing it already.



HUB: Deadly Danger Dungeon
WebClient: Deadly Danger Dungeon

Note: Known speech bubble bug for WebClient users. Lummox fixing it.

December Project Back Story:
I came across this game on another gaming site while pondering life and projects. While I was getting ready to dismiss it after a couple of plays, it occurred to me that even though that game was basically a pile of dung, it was better than any game I've ever produced. It was finished, it was published and it had a lot of plays. This realization just blew my mind a little. Where am I going wrong in my designs that I can't produce something better than that? I don't have an answer yet but it really struck a cord with me.

I dug into the game a little and found it has a fun back story with some amount of cultish fan-fare. I ended up finding an old YouTube video where the original designer had introduced the board game for the first time. It was something he had designed as a kid with friends.

You can watch it here

Note: The video has a lot of cussing in it.

Anyway, after being entertained by the video and my rude awaking, there was only one thing left to do...
Dec 14 2015, 6:06 pm
In response to Popisfizzy
Popisfizzy wrote:
I'm fairly sure what's happening is that BYOND is converting to a float on the fly as needed, though Lummox could possibly clarify. My reasoning for this is two fold:
  1. Negative integers are stored as two's complement (e.g., examining the bits of 0xFFFF and -1 show they have the same representation). Two's complement is not used in the mantissa of IEEE floating point numbers.
  2. Integers representable as 16 bits have the format you would expect when examining their bits. This is not true of floating point numbers. E.g., in IEEE single-precision floating point format, 1 is represented as 0x3F80000 rather than 0x0001.

All BYOND numbers are represented as 32bit IEEE 754 floats
Bitwise operators only work with 16 bits. The numbers are as big as the exponent/mantissa can hold.
Dec 15 2015, 4:10 pm
In response to Tobba
Tobba wrote:
Screenshotting lighting-related pictures turns out to be really iffy with most tools by the way; most seem to mess up the gamma somehow. Here's the same area from a page back with BYONDs own screenshot tool:

i like this a lot
Dec 15 2015, 4:22 pm
In response to Somepotato
Somepotato wrote:
All BYOND numbers are represented as 32bit IEEE 754 floats
Bitwise operators only work with 16 bits. The numbers are as big as the exponent/mantissa can hold.

Interesting. Does some sort of conversion to an int occur when doing bitwise math? Like I said, the binary representation of an integer is not the same as for a floating pint number.
Dec 15 2015, 4:55 pm
In response to Popisfizzy
Popisfizzy wrote:
Somepotato wrote:
All BYOND numbers are represented as 32bit IEEE 754 floats
Bitwise operators only work with 16 bits. The numbers are as big as the exponent/mantissa can hold.

Interesting. Does some sort of conversion to an int occur when doing bitwise math? Like I said, the binary representation of an integer is not the same as for a floating pint number.

More likely its converted to a short, hence the 16 bit limitation; I've been trying to push for the full 24 bit precision but to no avail.
Dec 15 2015, 5:01 pm
In response to Somepotato
Somepotato wrote:
I've been trying to push for the full 24 bit precision but to no avail.

That would be fantastic for this BigInt library. It would have a smaller memory footprint and (probably) be faster.
Dec 15 2015, 5:12 pm (Edited on Dec 15 2015, 5:18 pm)
As a general update on the BigInt library, I'm trying to figure out how to implement the Karatsuba algorithm to speed up multiplication. It's not too bad right now, and honestly I'm surprised that I can do something like multiply two 1000-hexadecimal digit numbers in ~1.5 seconds, but it definitely could be faster.

Right now, it takes 62,500 'steps' (iterations of my inner loop for multiplication) to multiply those two numbers. If I can figure out how to implement Karatsuba successfully, it should only take about 6320 multiplications, along with some additions and subtractions; I'm not too worried about addition and subtraction, as they're linear. I.e., to add two 1000-hexadecimal digit numbers, it would take 250 steps.

In any case, getting this implemented successfully would be great, but a huge pain in the ass. Inner functions would make it a lot easier, so it wouldn't be too bad to implement it in, say, Javascript, but it's gonna be more annoying in DM.

[Edit]
As a quick back-of-the-envelope calculation, for 62,500 iterations it takes ~1.222 seconds on my machine. That's roughly .02 milliseconds/iteration. Assuming this holds for an implementation of Karatsuba (a very big if, mind) then to multiply two 1000-hexadecimal digit numbers should take approximately 1/10 of a second. That I would be extremely content with.
Page: 1 2 3 ... 107 108 109 110 111 ... 349 350 351