New GB version coming... feature requests, anyone?

[arthur_gill@hotmaIl.com]

You mentioned that you can resize the screenshots area with drag/drop.
Could not see it working in the new beta, tho the amending/editing of the ini did work.. did I miss something?
New beta looking very good however, and the update is..
A) Very much needed.
B) Very much appreciated.

I keep all my gb's (and supporting files) seperate and in individual folders, and run everything standalone, so I have a ton of gamebases to update...
any .ini editing would need replicating X times ( my prob I know!)

Regards,
Arthur.

[.mad.]

i know i have mentioned it before.
but i NEED to ask once more before you retire.


if a program starts at $0400 filling the screen with text...



the RUN command fails after loading file from gamebase.
could this be fixed adding a colon to the command. (RUN:)
--------
if a filename contains [up arrow]



gamebase will not load /find the file when selected.


it tries to load [PI] instead??



THANKS FOR ALL YOUR WORK ON THIS!

[K.C.]

if a program starts at $0400 filling the screen with text...
the RUN command fails after loading file from gamebase.
could this be fixed adding a colon to the command. (RUN:)

I don't think so, because this is not Gamebase- but VICE-behaviour.
Unless you could give us the command line parameters to let VICE autostart an image with RUN: instead of RUN.
This CLP could then be implemented in the GEMUS script, this can't be done in the GB64 source code as far as I can see it.

[K.C.]

You mentioned that you can resize the screenshots area with drag/drop.
Could not see it working in the new beta, tho the amending/editing of the ini did work.. did I miss something?

After re-reading this thread I did not find anywhere that promised drag and drop feature you are talking about. Could you give us a link to the place where this is mentioned?
If I could choose between the 2 methods (ini files / drag and drop), I would go for the ini file method, like it is in the latest beta.
This will prevent the user from unwanted resizing of the screenshot window, but you can vary the sizes between different collections.
Most emulators use a fixed format for screenshots, in the ini file you can set the size to that format and there is almost never the need to change that size.

[Jimbo]

You can resize the screenshot selector window, not the actual screenshots area in the main gamebase window. I'm re-doing the options window at the moment, so you'll be able to set the fixed screenshot size (per database) via the frontend instead of the ini file. There will now be 2 options windows, one for general frontend options, and one for per-database options.

@.mad. Not sure how easy the up arrow/d64 stuff will be to fix until I get to it. Unless there's a way GB can send the right character then you might be out of luck.

[.mad.]

@ Jimbo
ok thanks for looking anyway.
just thought it was possible,
because when Loading in Vice i noticed it adds a colon.

Load"game",8,1:

thought it was in your super code not Vice.
---

One final suggestion from me. (promise)

now the game tab graphics are fixed.
can you make the Gametab window larger
so it is able to show a
24x24 gif & 32x32.gif
maybe changeable size in the UI

Thanks.

[arthur_gill@hotmaIl.com]

What is the 'screenshot selector window', vs the screenshot area in the main GB window? It is the main window I was suggesting in my initial posting.

regards,
Arthur.
[Edit] worked out what 'screenshot seelctor window' is.
Ahem.

You can resize the screenshot selector window, not the actual screenshots area in the main gamebase window. I'm re-doing the options window at the moment, so you'll be able to set the fixed screenshot size (per database) via the frontend instead of the ini file. There will now be 2 options windows, one for general frontend options, and one for per-database options.

@.mad. Not sure how easy the up arrow/d64 stuff will be to fix until I get to it. Unless there's a way GB can send the right character then you might be out of luck.

[Jimbo]

Hi Arthur,

The screenshot selector window is where you choose/assign your screenshots for each game.

There will be no drag/drop resizing of the screenshot area in the main GB window - however you can set the fixed sizes in the Settings.ini file, or (soon) in the "Options" window

James

[arthur_gill@hotmaIl.com]

doing screenshot window resizing...

Screenshot window not fixed at 320x200 (amiga shots look silly)

If I can get that working nicely with the window resizing I'll give it a shot.

[arthur_gill@hotmaIl.com]

Nice work on getting the screenshot window to be resizeable ... hopefully with drag/pull bars and not editing ini's?

No editing inis, you just resize or maximise the window.

[Jimbo]

ok, bit of a misunderstanding I think.

Screenshots in the main GB window can be set to a specific display size via ini file, they can not be resized by drag/drop.

The screenshot selector window (where you choose/assign screenshots for a game) CAN be resized/maximised.

[Jimbo]

New beta:
http://www.leesti.com/gbv13b20091217.zip

Latest full sourcecode package:
http://www.leesti.com/gbv13b20091217-src.zip

New stuff in this version: -
-- Can now show/hide/reorder fields in the details tabs
-- Options window split into "frontend" and "per-database" options
-- various small fixes/tweaks, see History.txt for full list

Feedback/bug-reports welcome as usual.

James

[Magnate]

the possibility to link more than one sid file to a game in a similar manner that extras are added. Numerous games use 2 or more sid files.

Bumping, just in case it went unnoticed.

[K.C.]

Nice update again, thanks!
In particular I like the way you can organize/hide fields in the details tabs.
But why make separate lists for the left and right side of the tabs?
IMO it would be better to list all fields, like in the Personal tab.

[Jimbo]

This was because some fields have longer possible text than others. E.g. if you put "cracker" on the right, it won't fit. To fix that whole scenario I'd have to give granular control over the exact (horizontal) positioning of the fields on each tab - which would probably be a lot of work to get it all configured with a UI for managing the layout etc.

This is a simple fix really due to time constraints - it doesn't go so far as to disable the "hidden" fields from the rest of the frontend either (columns, custom views, editing fields etc).