Dolphin, the GameCube and Wii emulator - Forums

I am working on a new game and I am considering having an online high score list. Now those are pointless unless you have some basic security, and I am thinking that just everything that leaves the application in encrypted, for example the xml save file is converted to bytes and encrypted with javax.crypto.spec.SecretKeySpec, and the same with all messages sent to the server. The decryption key exits somewhere in the program's binary (Java), is this "easy" to find?

In that case I am thinking of also generating a key code from the current time that must be valid when the server checks the message, similar to Internet banks. Figuring this out should at least pose a huge challenge I think.

Yes, it's easy to find these decryption keys.

The only way you have to do this kind of stuff is to have some "replay" file that the server can re-run to validate scores. Yes, it's difficult, and yes it requires some resources. No, there is no other way to make a secure high scores thingy. And even then that doesn't stop bots and cheaters to make perfect, TAS-like replays.

Stealing BSD code stay classy US gov't. Not to be outdone Oregon's exchange is going to steal some WTFPL code.

Well, my GBA emulator's coming along pretty fine. I think I have enough confidence in the actual ARM emulation to begin testing it in conjunction with LCD output. Most of the THUMB instructions are implemented (THUMB.1 to THUMB.16) and ARM.3 to ARM.5 are done. Currently getting minimal (and I mean absolute minimal) LCD functionality working. All it can do is fill the screen with the backdrop color. At least I can do that correctly in a small homebrew ROM I whipped up in a hex editor. It simply paints the screen green and that's it. So far so good though.

Keep up the good work shonumi

Having got monumentally pissed off at an excel spreadsheet we've used historically, I've decided to write my family a program that will manage what revel/humbrol etc. paints we need to buy in order to complete the vast collection of model kits we've bought over the years. The main body of it is a (mostly kinda) normalised database, but there are a couple of features I want that seemed to complicated to implement in MS Access, and as most computers my family use don't have Access anyway, it would have been silly. Therefore, as I know it best and it'll run on anything, I'm using Java.

It stores the following:

Paint - Each paint has a manufacturer, a number/code to identify it, an official name (e.g. black), and a finish.

Tin - Each tin is of a particular kind of paint, so has a manufacturer and code to link back. It can be acrylic or enamel, so there's a boolean to store if it's acrylic, and it's also got an approximate amount left, as it'd be silly to try and paint a huge kit if we've only got a drop of paint, and it's a pain when you get back from the shop to find the one colour you didn't buy has practically run out.

Need - A need is for a particular paint, so again has the manufacturer and code to link back, and has a boolean to say whether acrylic will do, and another to say whether enamel will do. Unfortunately, enamel paints are smelly and will ruin the airbrush my dad bought on a whim, and make up most of the paints we already have. This means that sometimes we can only use one of the types.

Equivalence - There are some colours multiple kit manufacturers both use, so they both make. That means I need to store a list of equivalents from other manufacturers for each paint.

I've also got two other classes so far, one for handling file IO, which has generic read and write methods that I've used before and know work, and another which wraps a HashMap holding the equivalences.

Anyway, this is the first thing I've ever written that I've ever put on GitHub, so if anyone's interested in finishing it all for me, it's at https://github.com/AnyOldName3/Paint-Manager

Picture time? I finally got something useful done as it relates to LCD emulation. I wrote another test ROM that actually tries to draw something to the screen using background tiles. It's just an alternating series of vertical black and white bars, but it works in my emulator and in VBAM. All the registers look right and so do the memory locations so that's progress. Next up, another test ROM but with more colors, and a more complicated background map.

I've abandoned the paint manager database thing because Cambridge want me to do a load of learning Haskell. Unfortunately, Haskell seems just slightly less aware of what it's doing than I need it to be. Ideally I'd have it realise that if a<b<c, and it needs to test all integers for each of a, b and c, then it should probably not iterate a to +infinity waiting for it to reach a value lower than 1, which b has, and instead when a is bigger than b, iterate b instead, and try again.

Thankfully, I've just thought of a rather nasty hack I can put in to make it not matter when it does completely the wrong thing.

Nice. Spent a whole day working on GBE+ (my in-the-works GB/GBC/GBA emulator) and it no longer exits due to unimplemented opcodes, nor does it segfault due to CPU bugs, at least for Super Mario Advance and Super Dodgeball Advance. However, all it currently does is show a completely black screen (so naturally no screenshots at this time. Timers and DMAs are unimplemented, and those are essential for running any commercial game. But it's exciting because I have worked enough to at least get this close to graphical output of any kind from something besides homebrew

Shounumi, will you be attempting to get your emulator to talk to Dolphin eventually, or are you going to leave that to Higan?

Anyways, hope to see it come to fruition some time