You are not logged in.

Read the FAQ and Knowledge Base before posting.
We won't make a 3DS/2DS emulator.

#1 Re: Support » Sands Of Destruction minor layering issue » 2018-08-01 10:58:04

Pretty late, but I figured I'd give pointers on this.

From what I understand:

Z values have nothing to do with this. Those of the concerned polygons are all zero. So even with an all-integer pipeline, they come out the same.

However, there's a depth-test edge case acting up. Apparently, when the incoming pixel is from a front-facing polygon, and the existing pixel is opaque and from a back-facing polygon, depth test uses function 'less than or equal' instead of 'less than'.

There are a few other cases that trigger this too, namely some cases of overlapping wireframe polygon borders, but this needs extensive testing to find all the cases.

Also, it is required that the viewport transform be accurate. They tweak their polygon positions slightly to influence Y-sorting.

#2 Re: General » long time no see, I guess » 2016-06-01 02:10:47 … g_ds_wifi/

seems like desmume got famous

oh and if you wonder where the actual sabotaging was: … /winpcap.h … /winpcap.h

r3602 renamed one of the pcap imports to something that doesn't exist (pcap_sendpacket -> pcap_send), which wasn't mentioned at all in the commit message.

r3636 was me thinking that there were pcap versions that actually had pcap_send.

r3639 was zeromus confirming that pcap_send doesn't exist and that he was just silently trying to sabotage code.

#3 Re: General » long time no see, I guess » 2016-04-26 20:14:01

you remind me of another reason why I left desmume

I'll be blunt and say that most of the code you have touched has become a giant mess

sometimes it's really good code (ie. your 3D rasterizer), but it comes at the expense of code readability

there are also other related things I'm not fond of, like packing a ton of statically-linked libraries into desmume-- the final executable is as big as PCSX2, which really says something given what it is

I'm sure there are some that can be removed, for example, why make the Windows frontend use glib threads (requiring a bunch of ports of Linux libraries) instead of native threads?

but honestly the best part was when you tried going behind my back and silently sabotaging wifi-related things -- is this the kind of interaction you would expect from a team? I have worked hard on that thing for ages and do I even get the slightest amount of credit for it? nope, because you decided that it had to be hidden from the public at all costs for whatever dumb reasons you made up (dealing with noobs? you released an emulator, too late. avoiding lawsuits? bullshit. avoiding severe forms of WFC cheating? not hard if you take the time to think it through.)

"but if they modify desmume to cheat, we're responsible" -- no we're not.

if a burglar uses a crowbar to break into a house, you don't say the crowbar maker is responsible for it.

the same logic applies if you don't go out of your way to make desmume allow that kind of cheating/hacking.

well, whatever. I might mess with DS emulation again eventually... but I will sure as hell stay away from desmume.

now I guess all has been said.

#4 Re: General » Just Curius but why isnt GBA emulaton supported on desmume? » 2016-03-01 00:07:11

zeromus wrote:

not that desmume's code isn't totally mucked up, but mucking it up more isnt going to help anything.


does it still map the ARM9 BIOS to 0x0F000000 instead of 0xFFFF0000?

#5 Re: General » long time no see, I guess » 2016-02-09 22:23:58

I figure; I tend to prefer working on things that have visible results though tongue

#6 Re: General » long time no see, I guess » 2016-02-09 20:26:40

looks like you've been doing some good job, I thought desmume was more or less dead these times, guess I'm proven wrong tongue

re: wifi

I understand your point, but the solution chosen is radical-- when you release an emulator, you'll always have to deal with hordes of noobs, and applying the same solution to the general problem would basically mean suppressing the emulator from the internet

sure, that'd get rid of the problem, but it's a bit of an easy solution

I'm not blaming you there though, I damn well know who's responsible for that

but that's not the whole reason why I lost motivation. It's mostly that from an emulation point of view, desmume reached a mostly-mature status, and therefore there isn't as much exciting work to do anymore imo

as for wifi, I kept trying but could never get local multiplayer working, it seems to require insane accuracy

and yeah, I'm doing well, I'm mostly into ROM hacking and emulation these days (you can check out my website for a little preview of what I'm into)

#7 General » long time no see, I guess » 2016-02-09 17:51:27

Replies: 13

nice to see this account still works (I'm now known as StapleButter for the curious)

"WiFi not emulated and not supported!!"

and nice to see that my hard work in that domain is still being shit on because "omg nintendo could sue us if people connected to their servers"

if you wonder why I have lost all motivation to work on desmume, that's one of the reasons

regardless, how are you guys doing?

#8 Re: Technical » WORKS : Open AL instead of ALSA for Microphone » 2010-06-06 21:44:38

Maybe your driver can't support the format being requested.

That format may seem nonstandard, but actually it's the format used by the DS's microphone, and we're too lazy to implement resampling tongue

#9 Re: Technical » [Windows port] Poll: Should translations be nuked? » 2010-06-06 21:40:08


Not to mention there are certain things which are English only and can only be made multilingual with extra perfectionism.

#10 Re: Technical » The WFC discussion thread » 2010-04-18 11:12:03


WFC now works (albeit unstably) since r3533.

From #desmume:
[13:02] <Manivo> Holy crap.
[13:06] <Manivo> So seeing as we're slowly progressing towards flooding big N's servers with pirate connections
[13:08] <Manivo> Here's an idea I had the other day. How about limiting wifi access for savefiles on which cheatcodes have been used?
[13:08] <Luigi__> that may be done
[13:08] <Manivo> Big N's fury might be sooner summoned if they had a flood of cheaters on their servers, rather than a flood of illegitimate players.
[13:08] <Luigi__> <- that has been discussed here
[13:08] <Luigi__> it is already possible to cheat on WFC using an ARDS
[13:09] <Luigi__> the real problem may be LUA
[13:09] <Manivo> I know, the difference however is that on an actual DS one needs to actually buy something, which limits the numbers of people who actually do that.
[13:09] <Luigi__> but seeing as it is enabled by a preproc definition, blocking wifi communications on LUA enabled builds shouldn't be hard
[13:09] <Manivo> Seeing as both desmume and AR codes are free..

What do you think?

Also, MKDS seems to be suffering from a timing problem as the WFC race starts. The bottom screen map becomes unstable and the 3D framerate drops to 25. I thought zeromus, our professional in timing problems, could perhaps look into that...

#11 Re: Technical » Emulator communication protocol » 2010-03-15 21:26:49

That sounds quite interesting! I hope it can help me with wifi development.

#12 Re: Technical » The WFC discussion thread » 2010-01-19 18:06:40

zeromus wrote:

That is a pretty good overview. I think you entirely left off the question of "What if hackers use desmume to CHEAT on the WFC servers?" We should find out the state of the art of WFC cheating via cheat codes, etc., to consider how much we would change that. There is an entire class of cheating which should be nearly undetectable, which would be done by lua scripts to create flawless (and sometimes prescient) playing. I guarantee you nintendo and other developers are nowhere near as ready to deal with cheaters as PC game developers are. But then again, how bad is it already?

I see. You mean if they use LUA scripts, or ARDS/whatever cheat codes while WFC-playing. Interesting point.
My answer: we should detect when the game tries to connect to the WFC servers (by looking for particular data in the packets being sent, I guess) and, when it's doing, block LUA/ARDS cheats.

And for what's hacking the WFC servers, I can't really find a purpose to it. Because I meant 'real' hacking, aka trying to get the servers down or to retrieve sensitive data from them (I don't think there's any in WFC though).
If it's hacking for cheating, well, interesting... depending on how much the user is cheating, it may or may not be noticeable by Nintendo. If it is, it is really bad for us. We should just block any cheats when WFC'ing. But this point may need more thinking and discussion.

But it is already possible to use an ARDS when WFC'ing, I think. And it hasn't been reported as crashing the WFC servers or whatever. So ARDS should be okay. The real problem is LUA.

yonizaf wrote:

well, Nintendo shouldn't know what MAC you use, because it's only used on the local network. unless they include it in the packet's data for some reason (unlikely), but then you could send them whatever else you want, and still use what you use on the real network.

however, the way things are now (same MAC for everyone) there's another problem: what if 2 or more people on the same network are using desmume (and wifi)? the MACs will collide, not good (I think). anyway, it should be better to randomize the MAC.

and, I was able to connect to freenode with ClIRC, though it seemed to work only after I ping'd desmume. wonder why.

The best way to know that is to record the packets being sent and look for the MAC address in them. There we have our answer.

Also, if you set DeSmuME to load a firmware dump, you'll be using the MAC address stored in your dump. But I agree, we should make DeSmuME generate different MAC addresses for each computer. Probably a MAC address like 00:09:BF:xx:xx:xx (where xx:xx:xx are the last three numbers of your computer's MAC address) would do it.

And about ClIRC. ATM, it works, but the connection is wonky. I'm looking for what could cause that. Maybe just your router having trouble acknowledging the presence of the DeSmuME "device". Mine had trouble too. But the connection is still wonky. I could connect to EFNet and talk on #dolphin-emu, but the connection timed out after a while.
The problem may be that SoftAP's current receiver can only read one packet every millisecond. There's high chance that packets are being missed.
I'm going to rewrite the receiving code so it can handle more packets per millisecond and also make it operate in nonblocking mode.

#13 Technical » The WFC discussion thread » 2010-01-18 22:21:58

Replies: 30

So yeah. The question is: are we allowing WFC connections from DeSmuME? Let's discuss this matter.

First of all, no comments like "plz make wfc work i rly want to play pokemon over wfc i rly want wfc blah blah".
If you know nothing about the technical part of the thing and just want to play pokemon over WFC, you will not be able to contribute to this discussion.

WFC currently doesn't work.

Let's assume it works.
- The default MAC address used by DeSmuME is always the same (00:09:BF:12:34:56). If Nintendo sees like 500 users with the same MAC address, it'll look suspicious.
--- We can force users to have a firmware dump.
----- But it wouldn't solve anything. People would all follow the illegal path and download the same firmware image with the same MAC address.
--- We can just take the MAC address of the user's computer.
----- But it could mess up his network.
--- We can generate a MAC address randomly from the computer's MAC address.
----- Maybe the WFC servers deny any connection from a device that doesn't have a DS-like MAC address.
--- We can make a random DS-like MAC address.
----- But chances are that it'll collide with existing MAC addresses.
--- But does the WFC protocol transfer MAC addresses at all?

- Maybe the WFC protocol relies on a precise timing.
--- It'd be a bad idea from Nintendo. Timings are unpredictable, mainly due to the fact the data has to go through your network, then the internet, before reaching the WFC servers.

- What if DeSmuME crashes/hangs/whatever during a WFC game?
--- Dunno. Maybe it'll crash the WFC game, maybe it'll crash the WFC servers (really, really unwanted), maybe it'll not affect the game apart from excluding the player who crashed.
--- I think it's more like "What if player X turns his DS off during a WFC game?". Aka, shouldn't cause big trouble.

- What if DeSmuME happens to send incorrect data to the WFC servers?
--- At worst, the DeSmuME user would get thrown out of the WFC game with a big "Communication error #12345" message, I think.
--- Unless the data is REALLY incorrect and the WFC servers' software is as badly coded as, say, the WiiOS (BannerBomb and other exploits come to mind). In this case it could crash the servers and even lead to hacking attempts from malicious users (really, really, really, really unwanted).

- What if hackers use DeSmuME to hack the WFC servers?
--- That's an interesting point. We'll make DeSmuME so they can't do it without modifying the source code, of course.
--- But what if they modify the source code?
----- We can just tell we aren't responsible for anything done with unofficial/modified builds, are we? We don't support those builds anyway.
--- After all, why would people want to hack the WFC servers? WFC doesn't transmit critical data anyway.
--- Assuming they really want to hack those servers after all. They'd rather use real hacking software, not DeSmuME, wouldn't they?
--- If someone hacked the WFC servers, I think Nintendo would look for their IP and report them to their ISP, rather than trying to shutdown emulators that are perfectly legal in themselves.

Feel free to discuss those points or other points I could have missed, and/or to prove me wrong.

Remember: no 'plz make wfc work i rly want to play pokemon with wfc plz'!!!

#14 Re: Technical » [Windows port] Poll: Should translations be nuked? » 2009-12-22 15:23:04


We won't nuke the translations right now.
However, any translation that is outdated and stays so before the release will be nuked.

Hoping everyone agrees with it.

#15 Re: Technical » [Windows port] Poll: Should translations be nuked? » 2009-12-11 17:48:13

There are 45 dialogs in DeSmuME. With 5 versions each (French, English, Chinese simplified, Italian and Japanese), there are 225(!) dialog templates in total. What a hell.

If we had, say, 16 translations, that would be 720 dialog templates.

I don't use translations either. Language option permanently set to English for me.
If people want to make unofficial builds with translations, then it's their problem. If people want to use unofficial builds, it's their problem. We don't support unofficial builds, period.

#16 Technical » [Windows port] Poll: Should translations be nuked? » 2009-12-10 17:29:38

Replies: 22

Reasons for not nuking them:
- They make DeSmuME multilingual.

Reasons for nuking them:
- They're a pain to manage.
- They will be more of a pain to manage when we support 23 languages or so.

I am in favor of nuking them.
Post your opinion in this thread.

Later on, we will see the results of the poll and take an action.

#17 Re: General » DeSmuME: Microfon-Support? Pen-Support? » 2009-07-09 17:07:26

Pen? Do you mean stylus? of course it's supported.
Microphone is supported too.

#18 Re: Technical » Request for comment: desmume save file format » 2009-05-29 21:42:07

So we suddently changed the save file format to proprietary?
I'm okay with this change ONLY if the conditions below are met:

1. If DeSmuME can load raw save files and convert them to its own format, just like NO$GBA
2. If the folder for save files is changeable, because otherwise it'll be a pain to manage the save files
because, when you run a game on another emu with a savefile created by desmume, the game will
most likely erase your save file.
3. If users can convert desmume saves to raw saves.

Board footer

Powered by FluxBB