An Idea for DeSmuME (kind of a request to the developers)

blinko · 2010-03-11 06:17:15

Hello Everyone,
I'm not sure exactly how to get a hold of the current project team members, but I am hoping they find this.
I was wondering if there was any way that we can split the top segment (screen) away from the bottom segment (screen), For example while I am playing The Legend of Zelda: Spirit Tracks. I'd like to be able to re-size my game window (bottom window with stylus support) and make ir larger while I am playing, and leave my mini map rather tiny since I do not use it as much. Can this be done currently?; and if not could we maybe work it into the next release? This way I can keep my mini map on the screen, and I'd have less trouble while using my mouse to click about. I tend to click off the side of the emulator often and it's becoming irritating.

zeromus · 2010-03-11 06:25:17

it can't be done right now. that feature isn't planned at all.

the next version of the emulator will have a feature to help keep you from clicking off the side of the window.

blinko · 2010-03-11 07:06:04

zeromus wrote:

it can't be done right now. that feature isn't planned at all.
the next version of the emulator will have a feature to help keep you from clicking off the side of the window.

I'm not really looking for anything to lock my mouse inside the game window if that's what you mean, those can be created easily.I think that this should be mentioned though, a feature such as this would probably put the icing on the cake for me. I wasn't even sure if this emulator would work on Windows 7, and other than the window resizing issue it's 100% great work.

I downloaded the source code for the win32 0.9.5 release. I may try to see if I can't just split the form into two pieces and recompile it, although, I'm used ot programming in other languages.

Last edited by blinko (2010-03-11 07:07:38)

zeromus · 2010-03-11 07:49:37

if you have that thing i said and enable it then you wont click off the side of the emulator at a all. What's not to like? If youre willing to build the source then get the latest svn build and try using alt+enter and view > window size > lockdown

You'll never be able to split it. good luck.

blinko · 2010-03-11 08:43:52

zeromus wrote:

if you have that thing i said and enable it then you wont click off the side of the emulator at a all. What's not to like? If youre willing to build the source then get the latest svn build and try using alt+enter and view > window size > lockdown
You'll never be able to split it. good luck.

There is the top and the bottom screen; since these are two different controls within the applications form, they should be able to be split up into two separate forms, and just use the code to render the video output to the correct controls. Kinda like splitting an image into two segments and filling the top and bottom windows with the corresponding cropped images, this is only theory at the moment.

Last edited by blinko (2010-03-11 08:46:50)

Manivo · 2010-03-11 13:01:47

Simple enough that anyone can do it, it seems!
You start.

blinko · 2010-03-12 14:06:18

Manivo wrote:

Simple enough that anyone can do it, it seems!
You start.

I think I will. Doesn't matter anyway no one else will have it, unless the developers implement it. So good luck to everyone using those tiny tiny windows lol. I've already got the bottom screen larger than the top, so everything is fine. Also using AutoIt you can do a simple _MouseSetTrap() to keep the mouse from clicking outside the window.

Check out the screen shot here. Hopefully the developers can come up with something similar in the upcoming releases, perhaps more properly coded that this one is, however, it is working. This is also done using an old 0.9.4 source code a friend of mine passed me.

The lower window I just pretty much kept the same format as the top, so either window will close the application upon exiting.

Last edited by blinko (2010-03-12 17:39:48)

zeromus · 2010-03-12 17:32:19

why dont you code this against the svn and submit a patch. I will warn you though that there are a ton of other options that it has to interact gracefully with somehow, which should be more work than the basic task of splitting the windows.

blinko · 2010-03-12 19:30:07

zeromus wrote:

why dont you code this against the svn and submit a patch. I will warn you though that there are a ton of other options that it has to interact gracefully with somehow, which should be more work than the basic task of splitting the windows.

The svn I got is 0.9.6 and it's slower than molasses.
The emulation speed is way slower than the 0.9.4 x86 version.
Hell it's even slower than the 0.9.5 x64 version which is probably the second best version of the emulator I have seen. I am curious though why the 0.9.4 x86 version is so much faster and smoother than the 0.9.5 version for x64 or x32. Aren't updates and bug-fixes supposed to "fix" such issues as emulation speed? and not bring them down further? Something somewhere got screwed up when they put together this svn, heck something went wrong when they compiled 0.9.5 in my honest opinion. But nevertheless congrats on the emulator to the developers, this truely is a good start.

Still with either version, certain shadows/tiles in game look screwed up.
There are line breaks on some of the rendered 3D objects, it appears as if the mesh hasn't been snapped together properly. This is obviously an emulation bug. For example as I've mentioned my Zelda playing. Running around most towns/dungeons you'll notice line breaks in the floor panels, and certain tile pieces looking chopped up. However the 0.9.5 x64 version does not have this issue, yet it runs slower...too bad.

Also why isn't the 0.9.5 x64 version .dst files backwards compatible with 0.9.4 x86 ?
This needs to be fixed...as it's super annoying and would be easier than using a hex editor to enable this.

Last edited by blinko (2010-03-12 19:48:33)

zeromus · 2010-03-12 20:04:46

Sometimes a bugfix comes at the expense of speed. Ever since 0.9.4 most bugfixes have come at the expense of speed. Perhaps you consider 0.9.4 "best" in terms of speed, but the svn is "best" in terms of features and game compatibility. There were no errors made in compiling 0.9.5; it just runs slower than 0.9.4. The svn wasn't "put together", it is just the latest development snapshot, with even more bugfixes and even more slowdowns. If you ran an svn binary that some asshat built, maybe HE did it wrong.

Shadows and mesh snapping together bugs havent really been addressed ever since the softrasterizer was originally put in. They'll stay broken until large chunks of the 3d get rewritten.

The savestate compatibility is never going to be fixed. Emulator internals change, and a dst is a dump of the emulator internals.

blinko · 2010-03-12 20:47:23

zeromus wrote:

Sometimes a bugfix comes at the expense of speed. Ever since 0.9.4 most bugfixes have come at the expense of speed. Perhaps you consider 0.9.4 "best" in terms of speed, but the svn is "best" in terms of features and game compatibility. There were no errors made in compiling 0.9.5; it just runs slower than 0.9.4. The svn wasn't "put together", it is just the latest development snapshot, with even more bugfixes and even more slowdowns. If you ran an svn binary that some asshat built, maybe HE did it wrong.
Shadows and mesh snapping together bugs havent really been addressed ever since the softrasterizer was originally put in. They'll stay broken until large chunks of the 3d get rewritten.
The savestate compatibility is never going to be fixed. Emulator internals change, and a dst is a dump of the emulator internals.

Well I can deal with the gamestate thing as long as the actual dsv files still work. How else would you start playing a game and continue on another build? As far as the svn is "best" in terms of features and game compatibility statement, I've only noticed that the line breaks do not appear in the svn either, so that's been brought over from the 0.9.5 build. But the svn runs completely slow, slower than the 0.9.5 which isn't all that much slower than the 0.9.4 really. Even if I keep my settings the same the 0.9.6 svn build cannot handle hardly anything. The rendering is slow, the sound is slow and choppy, there's flashing glitch spots all over it. This current 0.9.6 svn build is NOT stable by any means, so until someone with some coding skills gets under the hood, this hot rod won't be going anywhere so to say. I'll just stick to the 0.9.4/5 versions since they both for me have been 100% compatible with all the nds roms I've tried. All the games load properly upon gamestate loading, saving all works, sound is good. Crashes from time to time but hey thats windows 7 for ya. And honestly I think I'd rather stick with a few line breaks in the 3D wireframe, or even slightly slower with none on the 0.9.5 before I'll try to happily play using the 0.9.6 svn build.

zeromus · 2010-03-12 20:52:28

You're wrong. 0.9.6 is stable and handles more than 0.9.5 does. A far cry from "hardly anything." If you feel otherwise, please post details so that they can be investigated. p.s. With a sample size = 1, in the zelda main game engine, the svn runs 93% as fast as 0.9.5 for me. Also youd better make sure youre using the same 3d renderer in the different emulator versions.

blinko · 2010-03-13 02:11:26

zeromus wrote:

You're wrong. 0.9.6 is stable and handles more than 0.9.5 does. A far cry from "hardly anything." If you feel otherwise, please post details so that they can be investigated. p.s. With a sample size = 1, in the zelda main game engine, the svn runs 93% as fast as 0.9.5 for me. Also youd better make sure youre using the same 3d renderer in the different emulator versions.

Here's whats funny...this emulator seems to be working now near the same speed as the 0.9.5 I think it was the OpenGL i left there. The OpenGL for some reason causes all the characters in game to turn black. Once this happens it also becomes really slow. The softrasterizer seems to work rather well. Thank you for pointing out to check my rendering.

zeromus · 2010-03-13 03:07:14

I'm going to suggest that in the future you get a clue before you tell programmers to get skills.

blinko · 2010-03-13 04:35:08

zeromus wrote:

I'm going to suggest that in the future you get a clue before you tell programmers to get skills.

it's still slower which means it's lacking something, or else it needs something changed

zeromus · 2010-03-13 04:56:29

You mean, its still slower, which means that it is bugged, or employs greater precision, fixing some things necessarily at the cost of speed which can only be regained by optimizing other departments. Why don't you quit talking about things which you know nothing about? You'll sound a lot less foolish.

blinko · 2010-03-13 12:39:41

zeromus wrote:

You mean, its still slower, which means that it is bugged, or employs greater precision, fixing some things necessarily at the cost of speed which can only be regained by optimizing other departments. Why don't you quit talking about things which you know nothing about? You'll sound a lot less foolish.

Why don't you quit trying to be smart? Nothing should have been fixed @ the cost of emulation speed. That's simply poor code. It'd be the same as a web host wanted to offer more server space, but ended up lowering the upload and download speeds to and from the server. It's simple fix ONLY what needs to be fixed, leave the operational functions within the code alone, hell optimize it so it's all back up to par. Besides, for one so "foolish" I sure split the form that "wasn't possible" easily enough. People should think before they decide to program. It shouldn't be up to a passer-by such as me to make a patch for it, it should be the developers who do it, and do it right. Apply logic to your thoughts and ideas before you insult me.

Last edited by blinko (2010-03-13 14:09:46)

shash · 2010-03-13 14:48:11

Oh, we definitely need a hall of shame sub-forum for this kind of stuff, it would be more fun

Manivo · 2010-03-13 18:32:19

Your desktop is ugly.

zeromus · 2010-03-13 20:55:57

I found some bugs in the "screenshot" that you photoshopped.

Suppose for a moment that you took a screenshot with the small desmume window and then pasted the large desmume on top of it. Look carefully at the large window's shadow. Notice how it is mostly absent, except to the left where it seems to be the exact height of the smaller desmume window? This shadow must have come from a 256x384 desmume window hidden behind the larger one.

Look at the client contents of the small window. Notice how the greenish tinted stuff at the left edge directly abuts the light grey client area frame. You can especially tell near the tears in the bottom lefthand area. There is supposed to be a black column of pixels there from the client area frame. Then look at the right edge of the client area--uh oh! There is an extra black column of black pixels. Your window contents are slid over by one.

Look to the left of the desmume icon in the top window. You'll see that the shadow from the desmume window cuts out at the visual studio caption. If you think that maybe thats natural for some reason, then the fact that the black edge of the desmume window cuts out also surely couldn't be; at least for the one row of grey pixels which divides the VS menu bar from the VS caption, you can see on the right, desmume's black border overwrites it and the shadow too is in that row. I have no clue how this happened. Must just be a stray deletion accident.

A little odd, don't you think, that there are two windows with red X's? Usually only the foreground window has a red X. I suppose you re-engineered windows' entire window management system in order to accomplish this feat in desmume, allowing windows to have multiple foreground windows.

I'm not sure what this means, but its a bit odd that the icon in the bottom left has a row of pixels in the bottom that seems to overwrite the top black row of the large window's frame. Maybe it is JPG bleed.

I'm also not sure how you allegedly implemented this, but it seems to me a bit odd that the arm9 load average (01% vs 83%) arent synched. I would believe it if one window or the other never got the load average, but they both seem to have, and yet theyre not synched.

Putting visual studio in the backdrop was a nice touch though. You even picked the right file to open. But you know, the funny thing about visual studio 8 is as soon as you build, the output window opens. You don't even have it open in a tab alongside the error list. What, do you close it every time? Another funny thing is how visual studio 2005 doesn't display the selection rectangle in the solution explorer if visual studio isn't the foreground window. Since it is showing in your screen shot, VS mustve been in the foreground when you screenshotted it--not the desmume windows.

Your screen shot doesnt prove anything. Take 10 more screenshots with the windows in various configurations, and save them as PNGs; or post a patch against the 0.9.4 source code. Actually, I think I want both. Pics and patch, or it didnt happen.

Here's why your screen shot doesn't prove anything: I personally hacked desmume to run crysis, and then I added a UAV drone that flies overhead and gives you an aerial view in the other screen, so it is more DS-like; and my pic proves it:

Things must have been tough for you, using 0.9.4. It wouldve been easier if you had used 0.9.5 which has the natural ability to render only one or the other screen's contents in a single 256x192 window.

Here, let me show you how it is done

Next time you photoshop a fake app, switch to classic theme; it will be way easier.

shash · 2010-03-13 23:25:45

There's so much ownage in the last post, that we all should print it on tshirts, and wear them.

Ma77o · 2010-03-14 13:02:46

I'd wear that t-shirt.... Well played Zeromus, put the trash talker in his place!

Manivo · 2010-03-14 13:18:47

Fatality!!

XMSFel6 · 2010-03-14 23:38:16

OMG nice zero!

blinko · 2010-03-17 08:31:02

zeromus wrote:

I found some bugs in the "screenshot" that you photoshopped.

zeromus wrote:

Suppose for a moment that you took a screenshot with the small desmume window and then pasted the large desmume on top of it. Look carefully at the large window's shadow. Notice how it is mostly absent, except to the left where it seems to be the exact height of the smaller desmume window? This shadow must have come from a 256x384 desmume window hidden behind the larger one.

<---rofl the active window has no shadow, which would have been the bigger screen (lower portion of the emulator).

zeromus wrote:

A little odd, don't you think, that there are two windows with red X's? Usually only the foreground window has a red X. I suppose you re-engineered windows' entire window management system in order to accomplish this feat in desmume, allowing windows to have multiple foreground windows.

<-- simple two exact forms (same menu options command call's etc..) only difference is the control handles for the video output. This is also because eventually I'll have different options for both the screens.

zeromus wrote:

I'm not sure what this means, but its a bit odd that the icon in the bottom left has a row of pixels in the bottom that seems to overwrite the top black row of the large window's frame. Maybe it is JPG bleed.

<-- not sure exactly what ur trying to say, this only thing that comes to mind is I'm on Windows 7 operating system, and all of my windows have the opacity lowered giving them all a transparent look, so any color distortion is probably from that.

zeromus wrote:

I'm also not sure how you allegedly implemented this, but it seems to me a bit odd that the arm9 load average (01% vs 83%) arent synched. I would believe it if one window or the other never got the load average, but they both seem to have, and yet theyre not synched.

<-- the larger window is where i'm clicking to use the stylus etc.. it's going to run a bit higher than a window simply displaying an image if ya know what ur doing, this helps to enhance the larger windows performance speed.

zeromus wrote:

Putting visual studio in the backdrop was a nice touch though. You even picked the right file to open. But you know, the funny thing about visual studio 8 is as soon as you build, the output window opens. You don't even have it open in a tab alongside the error list. What, do you close it every time? Another funny thing is how visual studio 2005 doesn't display the selection rectangle in the solution explorer if visual studio isn't the foreground window. Since it is showing in your screen shot, VS mustve been in the foreground when you screenshotted it--not the desmume windows.

<--- This was simply opened in VS and then ran, no errors, no warnings as it should be.

This is also why I will not be releasing any patch for this, all people can do is flame on others. SO, with that having been said, enjoy your emulator you currently have and I'll enjoy mine the way I think it should have been done. This however, did make me giggle

zeromus wrote:

"Actually, I think I want both. Pics and patch, or it didnt happen."

; so you're going to basically call me a liar without having the slightest clue as to what your trying to prove, other than your oh so sherlock holmes "photoshop" detective work rofl, you STILL ask me to hand out a patch? If i had stupid tattooed on my forehead I might have, but since I don't you won't get your hands on anyhting...do it yourself if ya think you can. This is the beauty of programming, you can "virtually" do anything. Maybe if you're nice I'll give you a little hint as to where to start this process, till then my lips are sealed and this forum forgotten.

I'll be releasing a new style emulator soon anyhow, completely based on the DeSmuME SVN. Source code will NOT be given.

Peace

Last edited by blinko (2010-03-17 08:38:09)

#1 2010-03-11 06:17:15

An Idea for DeSmuME (kind of a request to the developers)

#2 2010-03-11 06:25:17

Re: An Idea for DeSmuME (kind of a request to the developers)

#3 2010-03-11 07:06:04

Re: An Idea for DeSmuME (kind of a request to the developers)

#4 2010-03-11 07:49:37

Re: An Idea for DeSmuME (kind of a request to the developers)

#5 2010-03-11 08:43:52

Re: An Idea for DeSmuME (kind of a request to the developers)

#6 2010-03-11 13:01:47

Re: An Idea for DeSmuME (kind of a request to the developers)

#7 2010-03-12 14:06:18

Re: An Idea for DeSmuME (kind of a request to the developers)

#8 2010-03-12 17:32:19

Re: An Idea for DeSmuME (kind of a request to the developers)

#9 2010-03-12 19:30:07

Re: An Idea for DeSmuME (kind of a request to the developers)

#10 2010-03-12 20:04:46

Re: An Idea for DeSmuME (kind of a request to the developers)

#11 2010-03-12 20:47:23

Re: An Idea for DeSmuME (kind of a request to the developers)

#12 2010-03-12 20:52:28

Re: An Idea for DeSmuME (kind of a request to the developers)

#13 2010-03-13 02:11:26

Re: An Idea for DeSmuME (kind of a request to the developers)

#14 2010-03-13 03:07:14

Re: An Idea for DeSmuME (kind of a request to the developers)

#15 2010-03-13 04:35:08

Re: An Idea for DeSmuME (kind of a request to the developers)

#16 2010-03-13 04:56:29

Re: An Idea for DeSmuME (kind of a request to the developers)

#17 2010-03-13 12:39:41

Re: An Idea for DeSmuME (kind of a request to the developers)

#18 2010-03-13 14:48:11

Re: An Idea for DeSmuME (kind of a request to the developers)

#19 2010-03-13 18:32:19

Re: An Idea for DeSmuME (kind of a request to the developers)

#20 2010-03-13 20:55:57

Re: An Idea for DeSmuME (kind of a request to the developers)

#21 2010-03-13 23:25:45

Re: An Idea for DeSmuME (kind of a request to the developers)

#22 2010-03-14 13:02:46

Re: An Idea for DeSmuME (kind of a request to the developers)

#23 2010-03-14 13:18:47

Re: An Idea for DeSmuME (kind of a request to the developers)

#24 2010-03-14 23:38:16

Re: An Idea for DeSmuME (kind of a request to the developers)

#25 2010-03-17 08:31:02

Re: An Idea for DeSmuME (kind of a request to the developers)

Board footer