UI Concept [wip]

[incantus]

For the image compression, yes 16 bit sounds nice, there's some improvement there, I really don't know gains of DXT. Still for indexed it would be gif, and WTH could actually take care of it, or have a small app to batch process things, I don't really think it would be a problem. Since I saw some obvious resource waste there, I did some quick tests to do a simple size difference measure.
How hard would it be for you to make it easy for me to change img formats, so I could load resources independent of file format, wich WTH would detect and load accordingly. It would then just output a txt file with the time taken to load an img and size in ram, this way I could try a bunch of different things to see what works best, with an easily quantifiable way.

It won't help to use indexed mode for the card images, because in the end the images will have to be rendered to the graphics card buffer, which doesn't use index mode. So chances are the images will be converted to full RGB after reading them in (and decompressing them), so you'll still have the same memory usage. If they are stored as indexed mode in memory, then they will have to be converted every single time they are drawn, which will probably be really slow (especially since you'll have to allocate the memory for the conversion anyway). The only solution is to use smaller images.

[wololo]

For the image compression, yes 16 bit sounds nice, there's some improvement there, I really don't know gains of DXT. Still for indexed it would be gif, and WTH could actually take care of it, or have a small app to batch process things, I don't really think it would be a problem. Since I saw some obvious resource waste there, I did some quick tests to do a simple size difference measure.
How hard would it be for you to make it easy for me to change img formats, so I could load resources independent of file format, wich WTH would detect and load accordingly. It would then just output a txt file with the time taken to load an img and size in ram, this way I could try a bunch of different things to see what works best, with an easily quantifiable way.

It won't help to use indexed mode for the card images, because in the end the images will have to be rendered to the graphics card buffer, which doesn't use index mode. So chances are the images will be converted to full RGB after reading them in (and decompressing them), so you'll still have the same memory usage. If they are stored as indexed mode in memory, then they will have to be converted every single time they are drawn, which will probably be really slow (especially since you'll have to allocate the memory for the conversion anyway). The only solution is to use smaller images.

Well that's not entirely true. The PSP has hardware capabilities to store compressed textures and indexed textures. So they would take less space without much loss in performance. BUT as incantus said, it does not depend on the initial picture.
Sure, it would probably be faster to load an image already in the PSP format rather than a jpeg, but an indexed png will probably not load faster than another png. The compression/indexation occurs on the PSP, not on the image software we use.
in the end, the total size needed in RAM for cards is the following: n*t + (f+u)
Where n is the number of textures than can be concurrently in Ram (i.e. number of cards in the cache), t is the size of a card texture in Ram (whatever their internal format is, indexed, 16 bits, 32bits, DXT...) and (f+u) is the space needed to decompress one file (probably, roughly : image file size f + uncompressed file size u).
The solutions suggested by alfatreze allow us to reduce f, which is not that big to begin with (a few hundred kb).
My biggest issue is to have n become bigger, so I have to reduce the size of t, which I believe can be done with a few hours of work on the JGE library. I believe (f+u) is very small compared to n*t.

[alfatreze]

Seems my ideas won't generate much optimization after all, oh well, better concentrate on the game mechanics and Interface concepts .

I was hoping to have some advancements on the easter weekend, but family and chocolates got the better of me, I hope everyone had a good easter holiday.


Take a lookhere at a pro program for image editing for game consoles, just in case some of the specific image formats they refer provides some ideas . I have and older version of the software (3.1 if I'm not mistaken, that offers most of the mentioned editing options).

http://www.webtech.co.jp/eng/istudio/spec_game.html
http://www.webtech.co.jp/eng/istudio/psp/f_psp.html

As for Interface advancements I've been thinking of a couple of ideas to enlarge board space and still have a good way to show previews of cards, but I need to properly sketch and test them, as well as incorporate most of the feedback in a more accurate way than freehand sketches.

The current UI's most flagrant problem is a big confusion with several ways of offering card previews as well as shifting locations, a good UI must be constant, just think of the orrible office 2003 disappearing menus, it's impossible to memorize locations properly.
I'm striving to find a way that solves this in 2 stages, board and hand, as they have specific requirements. I'm also aiming to create a standard design scheme that does not require original card images to be both visually appealing as well as easily playable.
One of the problems I'm facing and haven't really playtested, for not having the proper card sets, is card thumbnails. Does anyone easily recognize the cards based on thumbnails alone, both for the board, as well as the bigger hand ones. If not we need a mechanism that easily shows either the full card preview, or the essencial information. I'm thinking that for the hand the card name and casting cost is the most essential, and for the deck it would be the card name and abilities.
I've been considering a zoom preview system for the board cards, instead of the "always on" currently previewed, but it would probably need an helper to show extra info for the card, otherwise one keeps zooming all the time, I know I do. I must develop this further to see if it's actually feasible.

On another note, what would be the difference in memory usage on using a single image for drawing a background and tile a small one? I'm thinking that it keeps the small in chache, and then draws to the (framebuffer?videobuffer?) display, where the amount of resources used is constant independent of source. :S
Not sure If I'd use it anywhere yet, but knowing doesn't hurt.

I'll be sure to have something new by the weeks end, as I do want to test couple of concepts more thorougly.
Please help me drive my development with feedback and ideas, or simply describing problems in both current version as well as in the WIP interface.

Remember, there are never stupid ideas, only the lack of them is reproachable.

[megoder]

2 wishes

1. restrict pressing R-shift (phase change) with opened hand.
2.!!! non janapan users of psp use [X] for "yes" and [O] for "no" in game japan style control(O yes) needs option for switching this. i constantly miss O & X

PS sorry for bad English its second language.

[yoda01]

Any word on the status of this project? Looks pretty snazzy!

[wololo]

We are working on a few changes in the UI, that will involve some of the changes mentioned here, but are actually quite different.
I sortof lost contact with alfatreze so I'm not sure we can get a hand on his sleek graphics though