Print

[gilles9999]

Finally i have a SDTV at home, I can do all the tests i want!
The font used in the sdtv settings wasn't good, too bold
So i have used the "standard Trebuchet font" (f###ing hell to find this font ) in all the sdtv settings
and adjust all the texts, the graphic interface looks lot better in SDTV.
I keep the "Trebuchet bold" font in HDTV settings though Trebuchet is by far one of the best looking font (simple,clean, same used in xbmc)
The graphic interface is near perfect now (in my opinion, but i have a big sdtv)
madmab, is the text ok now with sdtv settings, or must i use a bigger size for the gameselect font?

http://www.megaupload.com/fr/?d=OW3BDFQ8

http://www.megaupload.com/fr/?d=VEY2KVFU

Oh! and madmab, my xbox doesn't freeze at all now, 0 freezes!
ressurectionX, is it ok for you too? Can you test my new skin with the new madmab beta?
update needed in mad and i thread rezx

[ressurectionx]

I gotta give it up for the weekend man.  I'm burnt out and need to get some sleep.  

Hopefully I can give it a shot sometime this week between work.  I'll get the new skins up ASAP.

Later,
~Rx

[madmab]

QUOTE(ressurectionx @ Nov 1 2008, 09:17 PM)

I see where you're coming from, but I think that it would be better for the end user to have different folders for each, if this is something that could then be easily ported from one emu to the next.  I think it would be kinda out of place for a perfected emu to have a little glitch of having to navigate to a folder depending on which media you're looking at.  

Ideally, way in the future maybe when the next emu-tweaker comes along and we're long done with our work, if you pressed "View Game Manual" in the in-game settings, it would pull up the manual for the game you're playing (if there is one).  I know how difficult that might be now, and there's plenty of other things to do before everyone can see how great these new features are, so I think it's still important to have the emu automatically navigate to the "Game Manual" folder instead of a generic "Documentation" folder.  I still think the same of the other types of files.  

I know that it's not a huge thing, but not taking that shortcut would greatly improve a small feature of your emu.  I'm putting a lot of work into the manuals and I'd like to get to some gamefaqs someday and I think they are important enough to warrant their own folders.  They could be defaulted to the "Game Manuals", "TV Commercials", "Gamefaqs", and "General Text Files".  I doubt anyone would put them anywhere else, so it's even unlikely that they'd ever have to change these options in the menu screen.
Later,
~Rx

Well each "user definable" directory I create takes up 500 bytes (I think) worth of space.  I'm not much of a memory expert when it comes to the xbox so I don't know if this will make much of a difference on emu's that are tight for memory.  But with that, the synopsis.txt, gameshark/genie codes, and predefined configs loaded up.  I'm really not sure how much of a memory hit I'm taking.  Then of course there are more menu options to add.  

Harcoded directory names though is a different story and would be easier and not take up memory like user definable directories.

Then again I could be wrong and memory might not be an issue.  I know I had memory difficulties with atarixlbox but that may have been more a "stack" space issue.  Unfortunately when it comes to that stuff I don't know much.

I'm just saying that I have no idea what kind of memory hit I'm taking with this stuff and how it will effect some of the other emu's.

[ressurectionx]

I see what you're saying madmab.  I never looked at it from a shortage-of-memory perspective.  I understand it, but since I really am not much more than a coding novice, it's way under my radar unless it's pointed out to me.  Thanks for taking the time to explain it to me.

Hard-coded seems to be the way to go.  Why give the user options on where to put this stuff if the emu could suffer from it, right?

I really think that these all deserve their own folders, and it will greatly improve the experience in subtle ways that would annoy people if they weren't done right, so I propose we do the following....

In the emu folder (or D:\) just make the emu point to pre-determined folders you provide that can't be changed as follows:

\Game Manuals\
\Gamefaqs\
\Text Files\  (For the general help, thanks, etc.)
\TV Commercials\

Then we can decide what the best way to access these folders would be from there.  Whether you are viewing any one of these from an option outside of the game, or in the "in-game" menu, it will only find files that the user puts into these pre-determined folders.  Probably a better option this way anyways because then there would be less clutter in the options and configurations menus.  Now that I think of it, there's no reason that the end-user should put these anywhere else except for the folders that come with the emu.

Before, the text files were just in the main emu directory, and that was fine when there really wasn't any, but as long as we can make a separate directory for them and have the emu point to it, I don't see a reason to clutter up the emu folder with text files.  

Just have to remember to put a .txt place holder in these folders when you release the emu so they will transfer over to the XBox before the user can add all the Xtras.

~Rx


Hey Gilles,

I got your new links up in your thread.

I didn't even notice that you said that there were 0 freezes before!  That's great!

I'll have to give it a shot in the next few days.  I don't think I'm doing anything on my days off, so if I don't get to it between work I'll take a look at it by Thursday.

We really got something special here and I can't wait till we get a release or two out there to show everybody what's been done.  Even though I want to have a release today, I'm really glad we're taking the time to get it right the first time on madmab's colecovision emu.  I know I'm not usually a "team player" (the only sport I did in High School was Wrestling) and that there are others I've worked with on the Box that are even less inclined to be team players, but I think it's great how well we work together and how we're enthused about it and as passionate as we are about it even though we aren't getting paid a cent for all of our work.  It's really nice to be a part of this and be able to give back to a community that has already given us all so much.  

Buy your extra XBoxes now guys.   These things will jump from 85 bucks to 200 bucks on eBay when we're done  

I'm not braggin' or nothing.  Most of the price increase will be due to the insane inflation that will happen before we're done, after the banks around the world drop the intrest rates to 0% and pump trillions of cash into our economies.  I just paid 4 bucks for a loaf of bread after tax today  

At least I have my XBox  

Take care guys.  I'm pooped.

Later,
~Rx

[madmab]

I'll have an update for my sticky threads when I can.  Didn't get a chance earlier today.

[ressurectionx]

Hey guys,

I was thinking about the sprites last night and got to thinking that if others started making new images and stuff for alternate looking emulators that this folder would get mighty confusing really quick.  I believe this would be a Gilles related fix, and not something madmab would have to do anything in his code for.  (Unless, of course, there were any XBox freeze type of memory issues)

I'm just thinking that if we had, say, 100 sprites in the folder, it would kinda be a mess for everyone to go through when making their own skin with the images.

I was wondering if you guys thought it might be a good idea to categorize the sprites in folders for you to select when you were altering your skin.

Something like this:

Skins\Animations\
Skins\Backgrounds\
Skins\Banners\
Skins\Borders\
Skins\Buttons\  (Geez... lots of B's, right?)
Skins\(Whatever we would classify the backdrops to the romlists)\
Skins\Misc\

etc, etc, etc....

Woah.... I just had an amazing idea!   What if we were to make one central "Sprites" directory on the E:\ drive?  If we separated the sprites into categories like this, there could be one single directory with all the sprites that any particular emu you're playing would point to that would contain all of the artwork, for all of the skins, of all of the emus.

For instance, we could put Gilles, Cospefogo's, Guybird's and Sotu's (and anyone elses) banners in the E:\Skins\Banners\  directory and just scroll through them when we want to control a sprite to display the banner on our emu.  

Then we could name them something like this:

E:\Skins\Buttons\
01_A
02_B
03_X
04_Y
05_ABXY Vertical
06_ABXY Horizontal

E:\Skins\Banners\
01_NES - Gilles
02_NES - Gilles (2)
03_NES - Cospefogo
04_NES - Guybird
05_NES - Sotu
21_SNES - Gilles
22_SNES - Gilles (2)
23_SNES - Cospefogo
24_SNES - Guybird
25_SNES - Sotu

(I've got two for you Gilles because I believe you've created more than one.  Others may have or may do so in the future too and be handled this way.  I also skipped from 05 to 21 between emulators because if we want to have an easy time in the future keeping things organized, we'd want to have empty spaces so maybe we only need to rename a few folders instead of 40 or 200 folders when/if somebody makes new sprites for us in the future.  Maybe we should make them 3 or 4 digit numbers (001_NES - Gilles, 002_NES - Gilles (2)) so we don't find ourselves in an unfortunate "Y2K" situation someday?)

This, I think, would be a great way to minimize any waste of space by centralizing sprites that are often used, and also give you an easy way to navigate through system specific sprites as well.  It would also give an easy single folder for anyone to add any non system-specific sprites to the collection without having to do it 12 times.  (Plus, it has the additional inadvertent function of giving a little plug and thanks to the artists for their personal touch to the emu skins with their names.)

Since we have a sprite system that displays previews of the sprites, I think it's a total win/win.

Let me know what you guys think.  

Later,
~Rx


PS.... man..... I just keep thinking of other great things about doing it this way.  Say we collect any more artwork you and your girl do Gilles, and anyone elses contributions (which I'm sure will come when the emus start being released), and we want to release an update with all of them neatly arranged to the public.  Wouldn't it be great to just be able to zip the entire thing up in one single file on megaupload and tell people just to delete their old E:\Sprites off their Boxes and just put the new one there?

No more making separate folders for sprites on every single emu out there, making us and everyone else update 12 or more emulators with the changes every time we release them.  

I love me things that are easy.    


PPS....

If you guys like the idea, just let me know and I'll put together the preliminary directory structure on it this weekend.  I have full sets of emulator banners from Sotu, Guybird and Cospefogo to add to Gilles skins already.  (I don't believe I've asked Cospefogo if it was okay to use his yet, but I will)  

If you REALLY like it madmab, you could give me a beta that uses the folder E:\Sprites\ in the next day or so and I can really give you guys one to test.

Later,
~Rx

[gilles9999]

Wait, wait wait! rez!
The idea is good, but unfortunatelly, there is a major problem:
-the backward  compatibility, actually the cool thing about the futures madmab emuss is it is compatible with the dynamic skin AND the old skins.With your system, the olds skins won't work

Instead i suggest, from my experience with the skin system and manipulation actually:
be able to classify the sprites folder(like before but even without the numbers, the emu could read the directory), ex:

Banner A
Banner B
Banner C
Buttons
Screenshots window A
Screenshots window B
Video window
 etc...

INSTEAD OF:

3_Banner C
5_Screenshots window A
9_Screenshots window B
10_Video window
15_Buttons
18_Banner B
21_Banner A
 etc...

And the ability to scroll fast through them
With this system, my dynamic skins won't be compatibles with old emus,but it's not really a problem

If the emu would be able to read the sprites folder "even without a number", it will be cool because we will be able to classify alphabetically the sprites folder it will solve this problem
And I don't think we will see more than, say...50 sprites for one skin, because, again, the sprites must be "a little" compatible with the background.That is why, just a alphabetical classification inside the sprites folder will be cool.
So a member will send us a banner, we ftp it in the sprite folder and... Cool It is classify alphabeticaly, i'm viewing this Banner at the letter B!

[ressurectionx]

I see what you're saying Gilles, but I really think this system is far superior, and I'm starting to get to the point of thinking that there is no reason to use any of the old skins with the new emulators.  If people want to re-do their old skins, or re-do somebody's old skins to be DYNAMIC than they can, but there's no way I'm going to use any old skins.  I figure if they want to use old skins, they have plenty of older versions of the emulators to use.

I'm going to make it this weekend for myself.  I'll upload it and let you give it a shot.  It will be easier for you guys to decide when you can see it in action instead of just read about it here before you decide.  

I will be making my skins work this way individually, with the hopes that you guys consider my idea and that we use a central folder for all the skins when the new emus are released.

The system we have now will be way too complex if there is ever 200 sprites per emu to choose from and we will have to add the new sprites in 12 different places when people make additions.

~Rx

EDIT:  You mention 50 sprites per skin, but I thought the idea was that we'd only need one skin in the end.  This way, it would be easy to bounce from background to background and add elements from different skins to the background.  I know that the sprites have to match pretty good to be compatible with a background, but I believe that many more of them will be compatible with each other artistically when we have more to choose from.  I don't see any reason why there can't be 500 or more sprites in the central directory one day to choose from if people see the great work we've done here and start making their own sprites to add.

[madmab]

Well one big problem is the emu loads all sprites into memory whether it uses them or not and that takes up memory.  If it's an animated sprite it takes up even more memory.  Too quote x-port documentation...

QUOTE

Also be aware of memory constraints.  Let's say you have a frame of a sprite called 0.png.  This picture file is 90 pixels wide and 130 pixels high.  This will get rounded up to a 256x256 pixel 32bit picture.  This means that it will consume 256x256x4 bytes (256KB) of memory.  If your sprite has 10 frames of animation, that's around 2.5MB of memory.  Keep this in mind before you make ultra-smooth moving sprites with hundreds of frames of animation.

You can check your available memory by going to Configuration -> Configure Skin -> Show Available Memory

As for naming conventions.  I'm not really willing to kill backward compatibility just to do it.  The emu relies heavily on positional information to keep track of which image a sprite is using.  Tracking a sprite by name would slow it down.  In fact the engine from what I can tell is capable of tracking more sprites than it actually does but it looks like x-port limited that purposely.  Most likely because of performance and/or memory issues.

I would also advise against spacing then numbers out.  I'm not really sure how the compiler allocates RAM.  But I do know it does not necessarily load things in numeric order.  If you have sprites numbered 1-5 and then jump to 10 that's a posible 4 entries that are using memory for no reason at all.

[ressurectionx]

UGGGGGG..... This totally sucks.  

I already see some of the problems because I spaced numbers out like 0001_ 0002_ 0101_ 0102_ and you have 100 blank entries in between when scrolling through sprites. (Though the emu isn't running slow or locking up, but that may just be because there are about 100 empty place holders in between that don't take up any significant memory instead of images that would)

I guess I'll just have to be happy with the way it is.  This is a major downer for me though.  Though everyone will be able to use the end product, the DYNAMIC skin is really only going to be truly editable by people who really know what they're doing and are willing to spend the time to add the sprites to 12 or more emulators.  Since we can't have place holders, everytime we add new sprites we'll have to take the time to re-arrange everything or else it will end up being a jumbled mess of shit.  (And we'll have to do that for every single emu we make sprites for as well).  

Not to mention, that the skins aren't truly dynamic like we thought, since we'll still have to have a folder full of different skins because of the lousy memory constraints and that the only way we can mix and match artwork is if we re-arrange the artwork on our computers for different configurations and then FTP them back to the XBox.

Yay.... I get to go to work on a serious down note.


Extra thought:  Backwards skin compatibility is meaningless.  If we make any changes that positivley effect the emu while destroying backwards compatibility I say we don't give backwards compatibility any weight to decide against it.  Nobody using these new releases would waste their time on old skins that don't take advantage of any of the work that you guys have done on this end and I have done on my end.  If somebody wants it bad enough, they'll remake them to fit within the boundaries of the new emulators or they won't be usable.

[madmab]

I can guarantee you that somebody somewhere out there will insist on using the old skins.  Besides the changes that would have to be made to implement any of the suggestions, as I mentioned, would just affect the performance of the sprite engine.

I think the changes done so far have taken the skins alot further from where they were.  Sure everything may not be in one nice easy convenient place.  But then I'm not interested in doing a total rewrite of something I barely understand.  The sprite/skin system encompasses a large amount of code.  A good percentage of which I do not even know what it is doing.  

As for backward compatiblity.  So far nothing I've done affects the functionality of older skins and may in fact encourage people to modify those skins to take advantage of the new features.  At least that is what I'm hoping.

The type of system your interested in would probably be better served with some type of generic skin editor, rather than relying on an emulator with memory constraints holding it back.

[Cospefogo]

Hey guys,

My first words on this awesome job of yours:
FEEL FREE to use ANY of the stuff I have published so far.
I'm glad to be useful to the scene.

And, a question:
Will the skins for the older Xport versions still working fine
on the new MadMab's versions?

FOUND THE ANSWER:
(Sorry, I did miss the paragraph!)

QUOTE

MADMAB:
As for backward compatiblity. So far nothing I've done affects the functionality of older skins and may in fact encourage people to modify those skins to take advantage of the new features. At least that is what I'm hoping.

Keep up the good fight!
Cospefogo.

[madmab]

Thanks for the offer cospefogo.  I'm sure that will be more useful to gilles999 than me.  Where are your skins anyways?  At the usual xbox skin sites?

Yeah I dont know if anyone every verified it.  But according to Nes6502, when he added movies, running the emu in HD with the fonts a certain size created performance issues.  The engine seems to be able to handle more sprites but was deliberately scaled back.  So the whole skin engine must already be pushing it's limit.  I know when I did atarixlbox that my Miner skin (which has alot of animated sprites) was giving me performance issues when I added the SAP player.  In fact I had to cut back on the rewind memory.

So all of that stuff causes hits in performance.  If someone completely wrote the skin engine from the ground up it could probably be done.  But that is something far outside my skillset.

FWIW RessX I appreciate the suggestions you guys are making.  I may not always want to do them, or think I can do them.  But I do shuffle them into the back of my mind.  Just ask Run088. He wanted streaming media off the network from the get go.  He had to wait 4-6 months before I finally realised that it was something that I could do.  

[ressurectionx]

I ain't mad or nothing, and a shit ton of stuff I've wanted to see implemented so far has already been done by both you and gilles, so I didn't mean to diminish all the great work you guys have done so far.  The work has been brilliant so far.

I just think there are ways that we need to brainstorm the skins thing because I know it can be better even given our constraints.  Leaving it the way it is, although it's a vast improvement, is still going to limit us or at least make a lot more work than we should have to do, when we have other people adding things to it.  I have several ideas now that I want to test out before going into detail.  

One that I can mention already and I think will work is this...

If we aren't able to go to the extremes that I was talking, I think we really need to be able to space out the different types of sprites to leave room to easily add new ones in the future without having to re-number everything to keep them in order.  when I tested spacing out the different types (like the buttons from the banners) I used 0100, 0200, 0300 place markers for categories and there didn't seem to be any hits on memory or performance.  (it was just annoying as hell to scroll through 94 empty spots to get to the next category of sprites).  I'm wondering if there is a way that the emu could automatically notice that there isn't a folder for particular chunks of numbers and would automatically skip to the next number with an actual sprite/folder instead of scrolling through a large group of numbers with no sprite.

For example, if I had the buttons with numbers 0001, 0002, 0003, 0004, 0005 and 0006 and then I didn't start the banners until 0100, 0101, 0102 etc, and then started the borders for the previews at 0300, 0301, 0302, etc. , is there a way we could make the emu skip straight from 0006 to 0100 as we scroll through the choices in the emulator if there isn't any folders/sprites currently for 0007 to 0099?




That's just one idea I have.  I've got others, but need to do more testing before I propose them.  One thought that I have is that the memory is only used when one of the "Configure Sprites" is set to use a sprite and not just by having the sprite in the folder.  I may have misunderstood what you were getting at when you quoted this:

QUOTE

Also be aware of memory constraints. Let's say you have a frame of a sprite called 0.png. This picture file is 90 pixels wide and 130 pixels high. This will get rounded up to a 256x256 pixel 32bit picture. This means that it will consume 256x256x4 bytes (256KB) of memory. If your sprite has 10 frames of animation, that's around 2.5MB of memory. Keep this in mind before you make ultra-smooth moving sprites with hundreds of frames of animation.

You can check your available memory by going to Configuration -> Configure Skin -> Show Available Memory

Just from my experience using it so far, I don't believe that memory is used by simply having the sprite in the sprites folder.  I think the memory is only used if the sprite is selected in the "Configure Sprite #X" option.  Otherwise, I believe that you could have 500 or even 5,000 sprites to choose from in that folder without any memory or performance problems.  

I will test that to make sure sometime this weekend and I will give you a sprite setup that has all of Gilles work and the banners from everyone previously mentioned in them as well and see if you can do anything with the whole "skipping unused numbers" thing I mentioned above if you want to give it a shot.  

Later,
~Rx


P.S.  You're probably right that people would still want to use the old skins, and I'm not knocking them or anything, but I figure that's what the old versions of the emulators are for.   I know on the Coleco and some of the Atari systems you're going to revamp other things, but I'm assuming that for emus like the NES, SNES and Genesis, you're basically just porting the revamped menu settings and the DYNAMIC skin configurations and not really messing around much with other tweaks, such as control configurations or anything since they're basically perfect otherwise.  That's why I think that if people want to use the old skins they can just use the old emulators for the most part as well.

I really don't think there is any place for Static skins that only have one preview window in our work here given the ability to virtually make your own skin and all of the Xtras I'm providing.  The old skins are so...... 20th century.  Just my opinion, but I for one will never use one of the old skins.

This coming from a guy who loves the XBox 360 skin on XBMC and used the "Glass" skins that matched the XBox 360 look.  I hate not being able to use them now, but I'm hoping somebody, perhaps the original artist, perhaps Gilles, or even somebody else wants to see them too so I can go back to using the XBox 360 skin in XBMC instead of the PM3 skin that I never really cared for.  I do like it in Gilles skins, but I just don't like how it is set up and works in XBMC, but it doesn't look as good on a whole to use the 360 XBMC skin with gilles PM3 skins so I'm kinda stuck now with the PM3 skin in XBMC.  

Just looking at it from that sacrificial standpoint, I just can't concieve why anybody would want to use the old skins that are so basic and non-user friendly compared to the new DYNAMIC skins.  Maybe you'll change your mind when other people make more basic DYNAMIC skin setups and we're not limited to only one choice of decor.

[madmab]

Believe me.  The code does load into memory every single sprite, whether it is used or not.  I had that issue when working on my miner 2049'er skin.  I had to remove my fancy dancy morphing intro screen from the sprites directory cause it was causing my xbox to lock up.

Which reminds me I'll have to point Giles to that and see if he thinks he can do something with it.  

The problem with numbering the directories like that is the code indexes the sprite by it's number so all those "tween" etnries are pointing God only knows where.  Most likely to memory that is in use elsewhere.  So there is always the chance of corrupting memory or hitting a bad pointer, etc.

I'm not familar with the MS SDK compiler to know what it does, but from my experience accessing memory that was meant for something else can get, well pretty ugly.  So if I modify the engine to load them sequentually well then it's gonna take a performance hit because now it has to search by name and not index.  Plus if someone goes and changes around the sequences then all existing skins will be no longer functional and the user would have to go in and manually modify them.  

Ultimately any major changes to the skin system pretty much would require a rewrite with optimization in mind.  It'd be nice to have someone else on the team with more experience in that area.  But for me it's a bit much.