Depends on what you're after. I'd say go for it, but then I'm on Vista 64byuu wrote: If I go with the Visual C++ model, I can write my code much cleaner and with no speed loss on Windows. But I'll suffer a ~10-15% speed penalty on Linux until GCC catches up to the 21st century. Is it worth it?
bsnes v0.038 released
-
- Trooper
- Posts: 376
- Joined: Tue Apr 19, 2005 11:08 pm
- Location: DFW area, TX USA
- Contact:
-
- Regular
- Posts: 347
- Joined: Tue Mar 07, 2006 10:32 am
- Location: The Netherlands
While I don't particularly like pinning apps and all that, I use my quicklaunch to run pretty much every program I have. I have a lot of stuff on my desktop, but that's mostly random folders with stuff I downloaded. Now I'm not saying my way is the best way, but it's fast - all I have to do is go down to the bottom of the screen and find the icon I need - most of them are easily recognisable. If I had to go to my desktop every time I wanted to open a new program that would be very annoying.FitzRoy wrote:The Win7 taskbar actually keeps the quicklaunch bar ... The taskbar is much too small an area to serve as a launch station for programs, it very badly needs to be reserved for actively running programs.
One more question, byuu, besides the icon thing.
http://img67.imageshack.us/my.php?image=oddpp6.png
I always wondered why the entire line of an entry doesn't highlight. I agree with the slight indent/padding whatever, I just wish it would highlight.
http://img67.imageshack.us/my.php?image=oddpp6.png
I always wondered why the entire line of an entry doesn't highlight. I agree with the slight indent/padding whatever, I just wish it would highlight.
-
- Regular
- Posts: 347
- Joined: Tue Mar 07, 2006 10:32 am
- Location: The Netherlands
Pixel art still beats it hands down for quality, but resizing isn't that difficult. It does it already of course, dunno if the quality could be improved. Wasn't the problem backwards compatibility with Windows 2k (which downsampled in appalling quality or something)?FitzRoy wrote:I wish it could be just one big one and the OS downsamples accordingly. Maybe that's harder than it sounds.
New WIP adds nothing new, but fixes Visual C++ compilation issues. Stopped windows.h from defining min/max again, disabled (bool)intmax_t stupidity, added a default: so VC doesn't assume a function has a blank return path, omitted -static on libco, and reverted to always using windres over rc. Express Edition lacks rc, and you already need GNU make anyway, so why bother supporting rc, too?
As you can see, all the other icons look much sharper.
It looks like the taskbar is only 32x32 ... yet the result looks really weird. Almost like the .ico file only has a 1-bit transparency mask or something :/Can you tell me what I should include?
As you can see, all the other icons look much sharper.
I have no idea ... don't see any other listview styles I can use that'd highlight the whole thing :/I always wondered why the entire line of an entry doesn't highlight.
Last edited by byuu on Tue Jan 13, 2009 3:14 pm, edited 1 time in total.
-
- Regular
- Posts: 347
- Joined: Tue Mar 07, 2006 10:32 am
- Location: The Netherlands
Here's a somewhat interesting guide, though it's a specifically tailored for their program:
http://www.axialis.com/tutorials/tutori ... icons.html
(their program does look attractive, if a bit overkill - you could always try the trial)
http://www.axialis.com/tutorials/tutori ... icons.html
(their program does look attractive, if a bit overkill - you could always try the trial)
-
- Regular
- Posts: 347
- Joined: Tue Mar 07, 2006 10:32 am
- Location: The Netherlands
I can't even guess as to why that's happening. All icons, including the 32x32 one display correctly in XP, why wouldn't they in Win7? I'd love if you could find some other open source program you know that doesn't have the issue and compare icon formatting. I want to know what's in mine that's causing this.
UPX cannot compress the icon which is used by the shell. It can, however, compress icons which are used internally by the program.Verdauga Greeneyes wrote:Remember that only works on Vista (and Windows 7) though. You still need the other sizes for Windows XP, unless you want to store it as uncompressed data. (though since you use UPX, wouldn't it be compressed anyway?)byuu wrote:Even if we need a 256x256 PNG-compressed icon, that's fine by me.
One last thing I'd like to try and get in before v039 if possible: I'd like to multi-thread the Windows user interface, so that the menubar can be entered without freezing emulation. Not sure if it's feasible.
Idea is to have hiro call CreateThread right off the bat, write a shell function to queue window creation events so that it gains thread affinity for each window. From there, let it sit in a GetMessage() loop. Other threads can send window messages, so the user-side of hiro should be free to modify things at will. Whenever the lib-side needs to send an event, stick that in a queue instead and replace hiro::run() with a function to pull events from that queue.
Problem spots could pop up everywhere: the various video / audio / input APIs might not like being given HWNDs without thread affinity. Given the abstraction between those driver wrappers and the user interface library, I can't create a simple message passing layer to send redraw requests. Plus that thread could be frozen anyway when inside a WM_ENTERMENULOOP event.
SNESGT manages it though, so it has to be possible ...
bsnes uses 16x, 24x, 32x and 48x at 256 and 24-bit color depth.
At a loss, myself. Maybe it's using the 24x for some reason, since the taskbar icons are slightly smaller than 32x?
Idea is to have hiro call CreateThread right off the bat, write a shell function to queue window creation events so that it gains thread affinity for each window. From there, let it sit in a GetMessage() loop. Other threads can send window messages, so the user-side of hiro should be free to modify things at will. Whenever the lib-side needs to send an event, stick that in a queue instead and replace hiro::run() with a function to pull events from that queue.
Problem spots could pop up everywhere: the various video / audio / input APIs might not like being given HWNDs without thread affinity. Given the abstraction between those driver wrappers and the user interface library, I can't create a simple message passing layer to send redraw requests. Plus that thread could be frozen anyway when inside a WM_ENTERMENULOOP event.
SNESGT manages it though, so it has to be possible ...
Pidgin uses 16x, 32x and 48x at 16, 256 and 24-bit color depth.I'd love if you could find some other open source program you know that doesn't have the issue and compare icon formatting.
bsnes uses 16x, 24x, 32x and 48x at 256 and 24-bit color depth.
At a loss, myself. Maybe it's using the 24x for some reason, since the taskbar icons are slightly smaller than 32x?
http://www.filehat.com/en/file/2450/sfclogo-ico.html
Try this one, I made it with the latest version of axialis. 16, 32, 48, and 256 with the 256 one PNG compressed.
If it fails, we'll mark them like henke suggests and try to find out why. My guess is that the presence of 24x24 was causing it to be used and upscaled before 32x32. What's confusing about these icon formats is that 24x24 doesn't seem to be used by Windows, yet it's included as an option. Going to save the icon in windows format, it gave me checkmarks for 16,24,32,48 and 256. Everything but 24x24 was checked by default. So is it or is it not a part of the standard? Confusing.
Try this one, I made it with the latest version of axialis. 16, 32, 48, and 256 with the 256 one PNG compressed.
If it fails, we'll mark them like henke suggests and try to find out why. My guess is that the presence of 24x24 was causing it to be used and upscaled before 32x32. What's confusing about these icon formats is that 24x24 doesn't seem to be used by Windows, yet it's included as an option. Going to save the icon in windows format, it gave me checkmarks for 16,24,32,48 and 256. Everything but 24x24 was checked by default. So is it or is it not a part of the standard? Confusing.
An interesting turn of events relating to the early discussion about Qt's license.
http://www.qtsoftware.com/about/news/lg ... dded-to-qt
With the March release of Qt 4.5 comes the LGPL. Rather unexpected, but there you go.
Obviously I'm not expecting all this existing UI work in bsnes to be dropped all of a sudden, because it's more or less working fine. But this makes Qt that much more reasonable for consideration.
http://www.qtsoftware.com/about/news/lg ... dded-to-qt
With the March release of Qt 4.5 comes the LGPL. Rather unexpected, but there you go.
Obviously I'm not expecting all this existing UI work in bsnes to be dropped all of a sudden, because it's more or less working fine. But this makes Qt that much more reasonable for consideration.
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
Got an uncompressed version? My version of Microangelo can't load it...FitzRoy wrote:http://www.filehat.com/en/file/2450/sfclogo-ico.html
Try this one, I made it with the latest version of axialis. 16, 32, 48, and 256 with the 256 one PNG compressed.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
Ah, I figured it out.
When you run a normal application, Win7 draws the window class icon. But once you pin a program to the task panel, it uses the program's associated icon instead. Try it: pin bsnes and the icon becomes clean.
This sucks from a programming perspective ... Linux does not have resource files to attach icons and images, and the icon+controller C source encoding is breaking Visual C++ compilation. I'm at a loss for how to keep things portable and optimal at the same time.
Still, I'm happy with the new icon. 16x, 32x, 48x and 256x are what Microsoft is apparently recommending for future apps, and it's only ~11k or so. Not worried about classic 24x and 64x.
Thanks a million for making the updated icon, FitzRoy.
When you run a normal application, Win7 draws the window class icon. But once you pin a program to the task panel, it uses the program's associated icon instead. Try it: pin bsnes and the icon becomes clean.
This sucks from a programming perspective ... Linux does not have resource files to attach icons and images, and the icon+controller C source encoding is breaking Visual C++ compilation. I'm at a loss for how to keep things portable and optimal at the same time.
Still, I'm happy with the new icon. 16x, 32x, 48x and 256x are what Microsoft is apparently recommending for future apps, and it's only ~11k or so. Not worried about classic 24x and 64x.
Thanks a million for making the updated icon, FitzRoy.