That looks great, :D, and should work well with the new UI. Essentially the first screen is just a title screen, without any menu elements rendered, just a few options. Going into the options renders a separate menu, which will use a separate background image.
CaptainHIT, that looks nice, as well, :D. The logo looks cleaner with that font and the background for the filelist does give me some inspiration.
I've got a general design for the interface where it uses menus to select the command you want to do, with the command highlighted. It's better than using button mappings as everything is on screen, so it's not possible to hide menus, like the configure screen on the older versions. I'm still working on the flow model for the Settings, as there are quite a few options that Snes9x/FCEUX will share.
After that I need to design the object type and behaviors. After I get that done, the implementation should be pretty simple as defining a menu item, and it's function, then moving onto the next one and so forth. Trying to shift gears into an object-oriented mindset is kind of hard after working so long on low-level ps2sdk stuff, heh.
I can send you all graphical elements separately as they are still saved in layers. I used "pretendo" font for the logo with N!ntend0's logo background with same color for the font. I wasn't sure about to use that "®" in the logo as it was in the original. I can remove it easily if you wish. I also used "pretendo" font for the commands, that is easy to change too. I also wanted to add a background image, but I thought by adding the more elements, the more would grow the size of the emulator taking space in memory. Sometimes plain menu and graphics look best in my opinion. That doesn't mean it doesn't need to be changed. I'm always open to ideas and requests. :)
Originally Posted by ragnarok2040
I'm fine for now, :D. The specification is still unstable, since the UI will be supporting various screen modes from 640x480i to 1920x1080i (using a scaled framebuffer). Some of the skin elements might need to stretch/shrink or be rendered using a repeated pattern. It's better to wait until I have a skin format finalized before working on textures. If I design it right, the UI and skin format will be pretty reusable, even on PC or other platforms, by using separate platform specific class implementations while using the same class prototypes. C++ makes it pretty simple, heh.
The textures/bitmap fonts won't take up any space in memory after they're sent to the vram, but skins need to be loaded externally, even the default skin to limit the elf size. If no skin/font is found, it'll use a basic skin using just rom0:KROM and a basic primitive here or there. Since I'm using libconfig, I can organize the skin elements into separate sections so customization can be pretty easily done using a set of common attributes.
I found that Pretendo font on deviant art, and the artist is pretty good, :D. I can make some nice buttons with it. As for the "®" symbol, it should only be used with properly registered trademarks, but "™" can be used for unregistered trademarks. I think it actually breaks the law to use "®" with anything that hasn't been passed federal registration, in the US, at least.
Right now, I'm currently dissecting the old FCEUltra code. Mostly just the input code, and the main emulation loop, and a few features I'd implemented that I can pretty much copy and paste for the new menu. I'm organizing it all into separate types of objects, *_*.
I'm trying to compile from the sources linked upwards (sep15 07) and I fail with the message
"gskit_texture_png undefined reference"
Anyone know why?
Not for sure, but I can hazard a guess.
Originally Posted by indrora
gsKit is a major graphics lib, and it has undergone a long series of changes over the years.
Most likely the version of it that you have installed is not compatible with that particular source code, such that it uses some function call not defined in your lib binaries, which is why you get an error at linking.
You probably had some warnings for the same function call earlier too, about missing declaration and assumed argument defaults, but such warnings are not fatal and will not interrupt the process, like a missing function definition at link time will do.
If you are serious about wanting to compile sources of widely differing generations, then you will quite likely need to do what I have done, in order to work with sources having conflicting lib update needs, which is to create several parallel ps2dev lib sets, which I can switch between by redefining a symbolic link indicating which of them is currently active.
That is how I handle my needs of compiling different versions of uLE and of OPL, which are unable to use the same lib versions for some things. Currently I have three separate such lib setups, two with different fixed-version updates for different versions of uLE, and one with the very latest libs for use in compiling OPL.
Each of these lib sets has its own storage folder, named "ps2dev1", "ps2dev2", etc, and these are linked to by a Cygwin symbolic link (also a Windows shortcut) stored as "C:\cygwin\usr\local\ps2dev.lnk", and this is what I refer to in my bashrc file as "export PS2DEV=/usr/local/ps2dev"
Thus my $PS2DEV references in all bash and make scripts will in fact refer to whichever of my alternate libs is currently linked by that symbolic link, which I have three simple bash scripts to redefine as needed. So I just drag-drop one of those scripts to the bash icon to run it, whenever I need to switch from one lib setup to another. When using other GUI methods than my DD-Cygwin setup, it might not be quite so convenient, but still no big deal.
You do need a fully working symbolic link implementation though, which makes me doubt that MinGW can do it right. But it works fine for Cygwin and should work identically for all Linux-based setups.
Best regards: dlanor
Will there be a new revision of FCEUx anytime soon? Reasons I asked is because I've tried just about all the revisions out there for FCEU and to play my favorite NES titles like Mike Tyson's Punch Out or Punch Out seem to be a bit slow. Other than that, everything seem to be running smoothly.
hey, just registered to try and confirm a bug i've found in the gui of fceux.
i have quite a amount of zipped nes roms on my mass drive (1700+), and sadly the file-choose-dialog doesn't display the roms in alphabetical order anymore; it did tho when i still had 1091 roms in a folder, so i was curious where that could come from (is it a fat32-driver constraint or is it a problem of the file-choose-dialog?).
i'm not sure if i'm using the "current" fceux revision either - it's B955?
there is a obvious work-around for that, of course (putting the roms in sub-directories) - but i still wanted to confirm
--- EDIT ---
another thing is a missing feature: to be able to choose from the roms inside a zip, since i have several roms inside a zip (J/U/J+T ...)
this would be really nice :3
I think the limit was 2500 so I don't think you hit it. There wasn't a sorting method, though, so the order was whatever order the files already had. I'm not sure if it was by timestamp or just the in the order the files were copied.
The zip support was built into fceultra and the port of zlib for PS2 only supports the gzip format by itself, which archives just a single file. The only code I have right now that works with multiple archived files is for tarballs like .tar.gz and .tar.xz, but it's not built into the new browser. There is a regular zip file implementation with zlib, so I think I can port that without too much difficulty, but it will take some time. I can add it after the new release :D.
is ps2fceu-0.9.3 ps2 the latest version???
I think I posted a release after that version, and then a few betas after the last version in this thread but almost every release had problems, really. I decided to take a break from it at that point because my old interface code was just horrible, lol.
I cleaned out the old user interface, but left in the ps2-specific changes in the fceultra source made by bootsector and myself so I could make a new version with the new interface later. I'm going to try to port the latest version of fceux, too.
That's after Snes9x, though, :D.