byuu's message board

I'm tempted, but $5000 for a punchline for an audience of one is a bit steep.

I have byuu on my ignore list. He never says anything important anyways.

Again this bullshit? Ok, an accurate emulator doesn't need high requirements? So implement an emulator this way and show us. You are completely wrong and you are a troll unless you show us some code.

Could you show us some code, please?

Thanks

Yes, it really does. The problem is that the shortcuts needed to make an emulator get its output numbers identical to the real thing will only actually give the same results with most games, not all (the exact amount varies by what shortcuts you use). Just playing Super Mario World perfectly isn't necessarily accurate; there are a lot of games with edge cases that make bizarre use of the hardware, and accurately all of them means skipping the shortcuts you originally took to make popular/simple games more efficient to emulate.

Considering a PC can effectively with some minimal opcodes represent the functions of the SNES opcodes, and with tweaks where applicable to suit, every step done on the SNES can be represented by the PC.
Considering the specs of the SNES, and its expected output of pixels to fit a relatively lower resolution which in general is not a very high number to calculate considering modern pc specs, and considering all numbers calculated by the SNES are done with 10Mhz for its consistent FPS, it is not a lot of numbers being done every second in the long run - the modern PC can do a much much larger amount of calculations of a number in a second.

Matching the calculation steps 1:1 of the SNES opcodes can be done to suit PC opcodes with tweaks to fit, and with minor steps to translate 'if this opcode is read in ROM, do this on x86 to correlate the arithmetic/logic'.
Those minor steps and the few numbers of a 10mhz console doing its numbers in a second and generally doing minor adjustments for synchronizing video/sound output and some input for consistency should not require many Ghz.

It's not transistor etc - it is matching math/arithmetic/logic steps of the SNES opcodes to readable math steps in an algorithm to perform math+logic operations on a ROM and its numbers to do calculations on the PC with minimal opcodes to match to do the same math steps the SNES does. It is a series of the most directly matching opcodes to do the same math steps the SNES does.

A chunk calculation of math on a ROM with parameters to get the expected output numbers that will be sent to video/sound/temp with some consistency for input/output timing done on a 10mhz console for numbers that generally fit into a generally lower number of ram should not require many ghz to do basic math for the same numbers and be consistent for input/output of sending numbers.

There is modes for something like fastskip or something, where you can let calculations go without timing consistent to a specific fps and the result is the game begins running much faster - this is a result of a generally low amount of calculated numbers being done on a much higher spec pc to have the game running at a much faster speed.

If you just do a straight run of calculations matching what the 10mhz console and lower resolution numbers would be (and of 65536 colours making the calculations much less) the amount of output strings you can get in a second on modern pcs without the synchronizing constraints for consistency directly should be quite a lot.

Seems that he already tried to study compression methods, but no one answered:

http://forum.codecall.net/user/34019-so ... tab=topics

7z compressed to 24kb, but he thinks 1kb should be the solution.

Wow. Just... Wow.

Edit: okay, so the file he describes... the actual image data could, maybe even would compress down to 1kb or less... But there's also information about the file itself -- headers and such, plus the archive's headers and such. Is that so hard to acknowledge? Is it so hard to imagine that if you put a ZIP file inside another ZIP file, the result can only get bigger?

I'm fucking dying.

Yeah, if the picture has only one color you could use some kind of RLE to compress to a minimum, but seems that he has a "general method" that works for the whole universe, and with instantaneous decompression.

Thanks.
A BMP example later in the thread using DEFLATE without a header went down to like 79B and could be shrunk to 50B when each pattern fits into 5 bits.
7z did 1KB, RAR 2KB and PNG 5KB (with 54B header for the BMP).

This with some brute forcing could get the file to the size of ~<50B direct without the bit pattern shrink like DEFLATE, and the programming forum apparently doesn't appreciate that using common methods used in schemes (including DEFLATE) like being specific to data arrangement for compressible/raw areas <and acknowledging distributing strings>, common strings, patterns of them and in a row with being specific to constraints (like exact variable bit strings than each byte scanned) and some brute forcing will also reduce a file.
The purpose is detecting compressible strings in a file, which a compression algorithm should be able to do, in the spectrum of data and bit combinations. Once constructed, it is very light to decode since the overall intensive compacted assembling is done for a 'seamless' reading.
That was not my issue.

As for a general estimation in the beginning of the thread on another example during a process before merging steps, it should still be much less than 7z/rar.


And my typo of 10Mhz than 20Mhz for SNES - still stands that a generally low amount of numbers are being calculated, and where video is commonly the majority of the resource allocation this is 32,768 colours (not 65536) on a max resolution of 512 × 478.

I can show the pdf writeup I did to demonstrate the concept of doing something like what DEFLATE does and a method a lot more specific than 7z/rar for anyone interested (with some constrained brute forcing and variable patterns than fixed byte scans) (in pm).

which you'll need to know how to uncompress the stuff, as those people on codecall.net have told you several times...

OK, byuu has officially declared this thread a train wreck, so anything goes...

The Doug and Alegend45 are officially pissed, which makes this supposed troll thread a success.
My question is: Where on Earth are vxbinaca, Braintrash, FirebrandX and Broseph? More hilarity required.

I ask myself this question every time another page is added to this thread.