Hi
Just a note to say I've started a new GameBase engine in .net.
Initially I am starting out by writing a library that will convert existing gamebase databases into, and interact with, a new database format in SQLite.
There will be 2 database files, a "master" db, and a "user" db. User data will be kept in the user db (such as personal prefs for each game, favourite, difficulty, rating, highscore, etc). This way new master databases can be released to everyone far easier (just replace a single file in your GB folder).
The plan is to also replace Gemus with a recognised scripting language (e.g. javascript, lua or something) with bindings to the functions that set ini values, run emulators etc.
Also the new database format is open-ended, so you can create all the tables and fields you want for your specific gamebase.
I'll keep you posted here... I expect it to take a few months!
Once it's at a decent enough point, I'll release on github for those that want to play (to potentially write a frontend/interface with it). If you're interested, let me know. I already have one friend who will write a frontend for it.
James
Welcome to the Gamebase 64 forums. An attempt to document ALL Commodore 64 gameware before it's too late!
New gamebase engine under development
Moderator: Jimbo
- .mad.
- Honoured Member
- Location: Lancashire
Post
WOW!
i can't wait to see the first beta.
try and keep GEMUS replacement very simple.
That's the reason why we love and use GameBase.
i would like to see a few new features.
editable bitmap fixed font 8x8 would be cool.
![Image](http://s11.postimg.org/3pgbpncrj/font.png)
then any c64 /nes / msx system font could be used in the frontend looking pixel sharp.
D64 images with heavily edited directories.
The runnable file can not be selected for a few demos.
if a name in the DIR is "" (double quote)
which on a pc would be just '.prg' (extension only)
not sure if it possible though.
i can't wait to see the first beta.
try and keep GEMUS replacement very simple.
That's the reason why we love and use GameBase.
i would like to see a few new features.
editable bitmap fixed font 8x8 would be cool.
![Image](http://s11.postimg.org/3pgbpncrj/font.png)
then any c64 /nes / msx system font could be used in the frontend looking pixel sharp.
D64 images with heavily edited directories.
The runnable file can not be selected for a few demos.
if a name in the DIR is "" (double quote)
which on a pc would be just '.prg' (extension only)
not sure if it possible though.
- Jimbo
- GB64 Team
Post
Any "frontend" stuff like fonts etc will not be part of this library but part of the/a frontend that uses it.
To be clear, I am writing a library... I do not have existing plans to write a frontend myself that uses it, however a friend of mine has committed to writing one... but it needn't be the only one.
Cheers
Gemus replacement will remain simple. And any existing scripts will be converted to the new format..mad. wrote:WOW!
i can't wait to see the first beta.
try and keep GEMUS replacement very simple.
That's the reason why we love and use GameBase.
i would like to see a few new features.
editable bitmap fixed font 8x8 would be cool.
then any c64 /nes / msx system font could be used in the frontend looking pixel sharp.
D64 images with heavily edited directories.
The runnable file can not be selected for a few demos.
if a name in the DIR is "" (double quote)
which on a pc would be just '.prg' (extension only)
not sure if it possible though.
Any "frontend" stuff like fonts etc will not be part of this library but part of the/a frontend that uses it.
To be clear, I am writing a library... I do not have existing plans to write a frontend myself that uses it, however a friend of mine has committed to writing one... but it needn't be the only one.
Cheers
![Smile :)](./images/smilies/icon_smile.gif)
- Jimbo
- GB64 Team
Post
Status update #1
Update #1: -
So I've been working a bit the last few weeks on the new GameBase engine library in .NET (c#). It's coming along well so I thought I'd give a status update on here.
First, here's a bit more information on what this library is going to do, that the current GameBase doesn't (or does, but not very well).
Database will be SQLite, not MS Access MDB...
This is mainly for cross-platform accessibility. Yes, I'm writing a C# library to interface to it, but there's nothing stopping someone else writing another one in c++, java, ios, whatever. SQLite has its plus points in that it's very easy to use, but it does have its drawbacks too (very limited ALTER TABLE syntax, for example). However... SQLite does give one really nice feature, which means...
The Database will be split into 2 files...
The "master" and the "user" databases (e.g. gb64.master.db and gb64.user.gb). The "master" database will contain all the game info etc that will be distributed with an update. The "user" database will contain all your personal preferences (highscores, peronal ratings, favourites, personal comments etc). This means when a new database is released (e.g. GB64 v 50) all you'll have to do is replace your gb64.master.db with the new one. There are other benefits to this, for example (in the future) you could send your user database to the master db maintainer, and they could import data from it.
GEMUS will be replaced with a javascript engine.
This makes it much easier to write scripts and introduce more functionality as time goes on (and I don't have to write my own parser
). Existing gemus scripts will be converted to the new format.
You will be able to choose your own database structure...
With the current GameBase, you can rename tables and fields, but you're limited to a specific set/number of them. With the new engine, you can create tables and fields however you want. You want a genres table? Create one. You want 3 levels of heirarchy in the genres table... add them. You want to link many separate programmers to a game instead of just one? Configure it that way. You want a games collection, a music collection and a demos collection in the same database? Create them.
You'll be able to link many files to each "game"...
Game files, music files, screenshots, videos, covers, scans, docs, etc. There are no limits in the new engine, you decide what you want to have linked to each "item" in your collection when you set your database up, and what to call them. Also, more info can be stored per file, such as a title, description, comment etc.
So that's a little overview of some of things being worked on. Here's where I'm currently at: -
I've got the API written to create and manipulate the "list" tables (those like publishers, genres, programmers, years, etc)... the stuff that games link to. I've got this to a point where I can use this API to import all the current list tables from the existing gamebase mdb database to the new sqlite format. So I'm currently writing an MDB database converter tool that serves as a great testbed for the API, and it's working well so far. You can create plain lists (e.g. publishers) or heirarchical ones (e.g. Genres with sub-genres). You can also modify these tables, add rows, edit rows, delete rows, same with fields. Basically the API is there now to completely configure the List tables that you want in your database.
I've also written a basic "ViewMaker" as part of the API which will return a "view" (i.e. a list of records from 1 or more tables, with one or more filters on them) to display in a frontend.
Bear in mind this is just an API at the moment, but any .NET developer should EASILY be able to write a nice frontend for this (once it's done!) by just doing the UI stuff, and calling functions in the API. There is already a friend of mine who has promised to write a frontend but if anyone else is interested in making one as I continue to write the library, PM me and we'll talk. The library will be going up on github at some point during it's development.
That's it for now. Stay tuned...
So I've been working a bit the last few weeks on the new GameBase engine library in .NET (c#). It's coming along well so I thought I'd give a status update on here.
First, here's a bit more information on what this library is going to do, that the current GameBase doesn't (or does, but not very well).
Database will be SQLite, not MS Access MDB...
This is mainly for cross-platform accessibility. Yes, I'm writing a C# library to interface to it, but there's nothing stopping someone else writing another one in c++, java, ios, whatever. SQLite has its plus points in that it's very easy to use, but it does have its drawbacks too (very limited ALTER TABLE syntax, for example). However... SQLite does give one really nice feature, which means...
The Database will be split into 2 files...
The "master" and the "user" databases (e.g. gb64.master.db and gb64.user.gb). The "master" database will contain all the game info etc that will be distributed with an update. The "user" database will contain all your personal preferences (highscores, peronal ratings, favourites, personal comments etc). This means when a new database is released (e.g. GB64 v 50) all you'll have to do is replace your gb64.master.db with the new one. There are other benefits to this, for example (in the future) you could send your user database to the master db maintainer, and they could import data from it.
GEMUS will be replaced with a javascript engine.
This makes it much easier to write scripts and introduce more functionality as time goes on (and I don't have to write my own parser
![Very Happy :D](./images/smilies/icon_biggrin.gif)
You will be able to choose your own database structure...
With the current GameBase, you can rename tables and fields, but you're limited to a specific set/number of them. With the new engine, you can create tables and fields however you want. You want a genres table? Create one. You want 3 levels of heirarchy in the genres table... add them. You want to link many separate programmers to a game instead of just one? Configure it that way. You want a games collection, a music collection and a demos collection in the same database? Create them.
You'll be able to link many files to each "game"...
Game files, music files, screenshots, videos, covers, scans, docs, etc. There are no limits in the new engine, you decide what you want to have linked to each "item" in your collection when you set your database up, and what to call them. Also, more info can be stored per file, such as a title, description, comment etc.
So that's a little overview of some of things being worked on. Here's where I'm currently at: -
I've got the API written to create and manipulate the "list" tables (those like publishers, genres, programmers, years, etc)... the stuff that games link to. I've got this to a point where I can use this API to import all the current list tables from the existing gamebase mdb database to the new sqlite format. So I'm currently writing an MDB database converter tool that serves as a great testbed for the API, and it's working well so far. You can create plain lists (e.g. publishers) or heirarchical ones (e.g. Genres with sub-genres). You can also modify these tables, add rows, edit rows, delete rows, same with fields. Basically the API is there now to completely configure the List tables that you want in your database.
I've also written a basic "ViewMaker" as part of the API which will return a "view" (i.e. a list of records from 1 or more tables, with one or more filters on them) to display in a frontend.
Bear in mind this is just an API at the moment, but any .NET developer should EASILY be able to write a nice frontend for this (once it's done!) by just doing the UI stuff, and calling functions in the API. There is already a friend of mine who has promised to write a frontend but if anyone else is interested in making one as I continue to write the library, PM me and we'll talk. The library will be going up on github at some point during it's development.
That's it for now. Stay tuned...
- .mad.
- Honoured Member
- Location: Lancashire
Post
I use MS Access to paste all my Gamebase entries in one hit.
Good to know i can still make a NEW Gamebase in the same OLD way and convert it. If i can not get my head around SQL.
This is an absolute must for me.Jimbo wrote:I'm currently writing an MDB database converter tool that serves as a great testbed for the API, and it's working well so far.
I use MS Access to paste all my Gamebase entries in one hit.
Good to know i can still make a NEW Gamebase in the same OLD way and convert it. If i can not get my head around SQL.
![Wink ;)](./images/smilies/icon_wink.gif)
- Jimbo
- GB64 Team
Post
You won't need to get your head around SQL
At the very worst case, you'll be able to use http://sqlitebrowser.org/
At the very worst case, you'll be able to use http://sqlitebrowser.org/
- K.C.
- Cool Member
- Location: The Netherlands
Post
Good to hear James, looking forward to a Gamebase replacement!
If there will be a conversion tool, you can still develop MDB-based collections and convert them to the new format.
At the other side, new features cannot be used (like a custom number of nested genres), as the current Gamebase frontend will not be updated (I assume).
Jimbo, I'm not sure if this is a Frontend- or Library-thing, but this should be a nice feature for the new frontend:
In the current frontend, you can specify one or more folders for games, screenshots, music files and extras.
If you also can select an ISO file, and the frontend is capable of mounting and using it (without using drive letters), for a lot of Gamebase collections, you don't have to copy hundreds of thousands of files to your file system.
Eventually you can add a 'real' folder (mandatory or optional) for supporting addition of new games/screenshots/extras.
![Cool 8)](./images/smilies/icon_cool.gif)
I understand your concerns. For Introbase, I have a master Excel spreadsheet that I use to generate the Gamebase database (import Excel sheet from Access)..mad. wrote:This is an absolute must for me.Jimbo wrote:I'm currently writing an MDB database converter tool that serves as a great testbed for the API, and it's working well so far.
I use MS Access to paste all my Gamebase entries in one hit.
Good to know i can still make a NEW Gamebase in the same OLD way and convert it. If i can not get my head around SQL.
If there will be a conversion tool, you can still develop MDB-based collections and convert them to the new format.
At the other side, new features cannot be used (like a custom number of nested genres), as the current Gamebase frontend will not be updated (I assume).
Jimbo, I'm not sure if this is a Frontend- or Library-thing, but this should be a nice feature for the new frontend:
In the current frontend, you can specify one or more folders for games, screenshots, music files and extras.
If you also can select an ISO file, and the frontend is capable of mounting and using it (without using drive letters), for a lot of Gamebase collections, you don't have to copy hundreds of thousands of files to your file system.
Eventually you can add a 'real' folder (mandatory or optional) for supporting addition of new games/screenshots/extras.
- freenit
- Keen Member
Post
Hi Jimbo , I am very happy that finally someone is working on a new frontend... but my question is if it will have support for video, meaning that when you select a game a video is displayed automatically , and can choose more than one video for each game ...
Have you seen other frontends like HyperSpin?
I think to have videos is awesome.
Thanks for your work.
Greetings.
Have you seen other frontends like HyperSpin?
I think to have videos is awesome.
Thanks for your work.
Greetings.
- Seiya
- Commended Member
Post
maybe support animated gif or small animation for default "no_picture" (animated gif, quicktime)
Retro Trailer V2
https://www.facebook.com/Retro-Trailer- ... 8226392007
REV'n'GE! Fanzine
https://sites.google.com/view/retro-emu ... n-and-game
https://www.facebook.com/Retro-Trailer- ... 8226392007
REV'n'GE! Fanzine
https://sites.google.com/view/retro-emu ... n-and-game
- Jimbo
- GB64 Team
Post
Update #2: -
It's been a bit slow since the birth of my 3rd child
but things *have* progressed a little...
The main thing being it's been re-factored so there is no longer only a "master" and a "user" database. Instead there is a "master", and then as many "add on" databases as you want (one will be the "user" database with your personal data). This makes it more flexible for people to easily add their own data to an existing gamebase without actually modifying the distributed master version. It also means these add-on databases will be dead easy to share amongst other gamebase users.
Also, (and you will either love or hate this), but the name for the library is now...
[slug]base
Reasoning being it's not just for games, but really the library could cope with any arbitrary data (demos, apps, utils, movies, etc.). I also like the word 'slug'
Of course, the actual frontend can be called differently, and your databases can still be called gamebases, demobases, appbases, etc. It's a more generic library for these kind of databases, so I think the name fits.
Thats all for now!
James
p.s. oh, and I'll look into the ISO thing, K.C.. The other requests are all frontend based, but there's no reason why they can't be built in. Video is a staple requirement these days!
It's been a bit slow since the birth of my 3rd child
![Smile :)](./images/smilies/icon_smile.gif)
The main thing being it's been re-factored so there is no longer only a "master" and a "user" database. Instead there is a "master", and then as many "add on" databases as you want (one will be the "user" database with your personal data). This makes it more flexible for people to easily add their own data to an existing gamebase without actually modifying the distributed master version. It also means these add-on databases will be dead easy to share amongst other gamebase users.
Also, (and you will either love or hate this), but the name for the library is now...
[slug]base
Reasoning being it's not just for games, but really the library could cope with any arbitrary data (demos, apps, utils, movies, etc.). I also like the word 'slug'
![Wink ;)](./images/smilies/icon_wink.gif)
Thats all for now!
James
p.s. oh, and I'll look into the ISO thing, K.C.. The other requests are all frontend based, but there's no reason why they can't be built in. Video is a staple requirement these days!
- taulore
- Keen Member
Post
Just spotted this one and had a good read through.
Jimbo, I'm glad to see you are back at it and creating another frontend for our beloved Gamebases etc.
I like the fact that you are moving on from Access based databases. Access doesn't handle databases over 1GB very well and what with the ever expanding uses that Gamebase has been used for, this may become an issue in the future.
I find it exciting that you will be able to add databases to the system and that you have the ability to change the structure of said databases by linking multiple fields.
My fear though, is that the frontend will become less user friendly. There are other frontends out there and I have used most. But GB has always been my frontend of choice as everything that I require is there in front of me. I don't have to open another window to view graphics or read rom information. It may not have all the features that others have but it is the most accessible.
Jimbo, I'm glad to see you are back at it and creating another frontend for our beloved Gamebases etc.
I like the fact that you are moving on from Access based databases. Access doesn't handle databases over 1GB very well and what with the ever expanding uses that Gamebase has been used for, this may become an issue in the future.
I find it exciting that you will be able to add databases to the system and that you have the ability to change the structure of said databases by linking multiple fields.
My fear though, is that the frontend will become less user friendly. There are other frontends out there and I have used most. But GB has always been my frontend of choice as everything that I require is there in front of me. I don't have to open another window to view graphics or read rom information. It may not have all the features that others have but it is the most accessible.
Return to “The GameBase Frontend”
Who is online
Users browsing this forum: No registered users and 51 guests