I've been working on a VB.NET version of GameBase for a while (i.e. converted from the original VB6 code). I started this last June (based on v1.1), then put it on hold for a while, and I've now incorporated the changes from v1.2. I'm not quite sure whether James (or anyone else) is planning to continue development on the current version, so I'm happy to call mine "GameBase 1.3" or "GameBase.NET 1.0", whichever people prefer.
The current version of GameBase basically assumes that you're logged into Windows as a local administrator. (That's why the documentation advises you not to install it under "C:\Program Files" on Vista.) That's probably true for most people, but it's not ideal from a security point of view. So, the main change in my version (and the reason I started it) is that it will run properly as a limited user.
I'm also trying to get it working entirely in "managed code"; in particular, I hope to replace the embedded assembly code with the equivalent VB code. This means that it may work on other platforms (e.g. Mac OS X) via Mono, but I can't test that, so I'll need someone else to investigate for me.
I'm using v2 of the .NET framework, and the downside is that you need to use Windows 2000 or later, i.e. 2000/XP/Vista; it won't work on Windows NT/95/98/ME. Is that going to be a problem for anyone? (I'll get my version to include the OS version in the usage statistics.)
The current version of GameBase uses ini files to store strings for the user interface, the idea being that you can convert it into a different language if you want to. Has anyone done this? I'd prefer to centralise that, i.e. have all the different languages included in the compiled code, and this should reduce duplication of effort (rather than several people doing translations independently). It also means that I can adjust the layout of forms if needed, e.g. making buttons a bit wider for the German version (since their words are typically longer).
If all goes according to plan, I should have a beta version available by the end of May.
Welcome to the Gamebase 64 forums. An attempt to document ALL Commodore 64 gameware before it's too late!
GameBase.NET
Moderator: Jimbo
- K.C.
- Cool Member
- Location: The Netherlands
Post
One thing I am missing in the frontend is a way to edit the genres. They are stored in the MDB file, but can not be edited with the frontend or the toolbox. For an application ad tools gamebase I am working on, I don't have anything at "Shoot-em-up's" and "Arcade - Miscellanuous". I want genres like "Text - Word Processing" and "Hardware - Diagnostics".
I can edit these fields with Microsoft Access, but it would be more elegant to do this directly in the frontend or toolbox.
Re: GameBase.NET
Great! Can't wait until you make the beta available!JohnCKirk wrote:I've been working on a VB.NET version of GameBase for a while.
True. But I found a workaround to get it running for limited users. See this thread.JohnCKirk wrote:The current version of GameBase basically assumes that you're logged into Windows as a local administrator.
I have edited these ini files to use some fields for other purposes. For example , I have 'translated' the field 'High Score Saver' with 'Border is used' for a collection of C64 intros I'm working on. So I would like to keep the translations stored in an external file, or at least in a way it can be edited.JohnCKirk wrote:The current version of GameBase uses ini files to store strings for the user interface, the idea being that you can convert it into a different language if you want to. Has anyone done this? I'd prefer to centralise that, i.e. have all the different languages included in the compiled code.
One thing I am missing in the frontend is a way to edit the genres. They are stored in the MDB file, but can not be edited with the frontend or the toolbox. For an application ad tools gamebase I am working on, I don't have anything at "Shoot-em-up's" and "Arcade - Miscellanuous". I want genres like "Text - Word Processing" and "Hardware - Diagnostics".
I can edit these fields with Microsoft Access, but it would be more elegant to do this directly in the frontend or toolbox.
- Pugsy
- GB64 Team
- Contact:
- Location: North Wales, UK
Post
Out of interest will it be compilable with "Visual Basic (.NET) 2008 Express Edition" part of the free Microsoft Visual Studio Express 2008?
Gamebase64 Team Member http://www.gamebase64.com
Ex-freelance cheat listing/pokes contributer to Zzap, CF, CU & ACE
MAME Cheat File Maintainer http://www.mamecheat.co.uk
Ex-freelance cheat listing/pokes contributer to Zzap, CF, CU & ACE
MAME Cheat File Maintainer http://www.mamecheat.co.uk
- JohnCKirk
- New Member
Post
I'm using Visual Studio 2005 Professional Edition, so the code will work fine in the Express version of 2005 too. In fact, you can even compile it from the command line as long as you have the SDK (free download from Microsoft, included with Visual Studio).
As for 2008, I haven't tried it out yet, so I'm not sure how well it will work with that. I'm guessing that it should be ok, but you may need to make a few small changes.
Yes and no.Pugsy wrote:Out of interest will it be compilable with "Visual Basic (.NET) 2008 Express Edition" part of the free Microsoft Visual Studio Express 2008?
I'm using Visual Studio 2005 Professional Edition, so the code will work fine in the Express version of 2005 too. In fact, you can even compile it from the command line as long as you have the SDK (free download from Microsoft, included with Visual Studio).
As for 2008, I haven't tried it out yet, so I'm not sure how well it will work with that. I'm guessing that it should be ok, but you may need to make a few small changes.
- sixstringmonk
- New Member
Post
VS2008 should be fine. However, once you open it, VS2008 will modify the project and solution files and they won't be usable in 2005. Visual studio 2008 has new things such as .net version targeting so it has to add additional settings to the project files. The code and solution/project structure is not modified by the import process from what I've read however.
I guess if you ever decided to truly open source the project (to let other developers help you), all of the developers would have to use the same version of visual studio.
As far as mono compatibility goes, I think it would be REALLY neat, but probably a ton of extra work. I have no experience in that area, so I don't know what type of design considerations you'd have to take. I've been meaning to learn a thing or two about Mono now that the development tools are there and there is some form of winforms support. You might want to take a look at: http://www.mono-project.com/Guide:_Port ... plications
I guess if you ever decided to truly open source the project (to let other developers help you), all of the developers would have to use the same version of visual studio.
As far as mono compatibility goes, I think it would be REALLY neat, but probably a ton of extra work. I have no experience in that area, so I don't know what type of design considerations you'd have to take. I've been meaning to learn a thing or two about Mono now that the development tools are there and there is some form of winforms support. You might want to take a look at: http://www.mono-project.com/Guide:_Port ... plications
- iAN CooG
- Keen Member
- Contact:
Post
Not at all, you don't consider the fact that vs2008 executables are for XP/vistass only. People using win98 like me will be cut out. And I know many ppl not caring about "upgrading" (lol) because w98 is enough for us.sixstringmonk wrote:VS2008 should be fine
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- JohnCKirk
- New Member
Post
In the short term, I'm sticking to VS2005 (for various reasons), so this won't be a problem for now. In the longer term, my understanding is that you have a choice of framework in VS2008: if I target v2 of the framework then the resulting programs will still work fine on Windows 98.
v3.5 of the framework will only work on XP/Vista (source:
http://msdn.microsoft.com/en-us/library/bb882520.aspx), but I won't be using that in the near future. Anyway, it's useful to know that there are still GameBase users on Windows 98, so thanks for that.
Actually, I was slightly wrong there: v2 of the .NET framework will work ok on 98/ME as well as 2000/XP/Vista, so it's just people on 95/NT who will be out of luck. (Source: http://msdn.microsoft.com/en-us/library ... S.80).aspx)johnckirk wrote:I'm using v2 of the .NET framework, and the downside is that you need to use Windows 2000 or later, i.e. 2000/XP/Vista; it won't work on Windows NT/95/98/ME.
Are you talking about the programs that are written in Visual Studio (e.g. GameBase), or do you mean Visual Studio itself?iAN CooG/HF wrote:Not at all, you don't consider the fact that vs2008 executables are for XP/vistass only. People using win98 like me will be cut out.
In the short term, I'm sticking to VS2005 (for various reasons), so this won't be a problem for now. In the longer term, my understanding is that you have a choice of framework in VS2008: if I target v2 of the framework then the resulting programs will still work fine on Windows 98.
v3.5 of the framework will only work on XP/Vista (source:
http://msdn.microsoft.com/en-us/library/bb882520.aspx), but I won't be using that in the near future. Anyway, it's useful to know that there are still GameBase users on Windows 98, so thanks for that.
- sixstringmonk
- New Member
Post
My god, I'm having problems posting today because the pages seem to be getting cashed somewhere between here and there, so if this is the 5th variation of the post you've read, I apologize.
Anyway - probably stating something already known to everyone here, but 3.0 and 3.5 are just extensions to .net 2.0. Depending on what 3.5 features you'd want, you can get them to compile down fine to a 2.0 binary. For example, I know that you can get extension methods to compile down to 2.0. I'm not sure if LINQ will or not. I see LINQ and Extension Methods to be two very useful language features. WPF (Avalon) for sure a legacy breaker. Anyway, that's just info for if you ever did decide to go to 2008 and wanted to keep Legacy compatibility.
Anyway - probably stating something already known to everyone here, but 3.0 and 3.5 are just extensions to .net 2.0. Depending on what 3.5 features you'd want, you can get them to compile down fine to a 2.0 binary. For example, I know that you can get extension methods to compile down to 2.0. I'm not sure if LINQ will or not. I see LINQ and Extension Methods to be two very useful language features. WPF (Avalon) for sure a legacy breaker. Anyway, that's just info for if you ever did decide to go to 2008 and wanted to keep Legacy compatibility.
- Brataccas
- Keen Member
Post
When making the changes for v1.2, I first thought migrating to .NET wouldn't be too bad, but quickly realized this is a huge task. It would be really convenient for development if you manage to pull this off!
I'll be glad to update pnglib.dll or help out as things progress.
I'll be glad to update pnglib.dll or help out as things progress.
- JohnCKirk
- New Member
Post
I see that your BBC GameBase comes with several .sap files in the Sounds folder; are they supposed to be there, or were they copied in by mistake from your Atari project?
Changing the text on the buttons etc. is easy enough, and I see that you've already modified the text.ini file for that. Processing the files (e.g. to extract composer info) and launching the relevant application to play them is a bit more tricky, but I'll do what I can; any info on file formats etc. would be useful.hardmanm wrote:Sounds great, could you remove C64 specifics from gamebase.net i.e music files rather than sid files which refer to c64 music files. Will test the beta version when public with my gamebases i have created.
I see that your BBC GameBase comes with several .sap files in the Sounds folder; are they supposed to be there, or were they copied in by mistake from your Atari project?
- Patch61
- New Member
- Location: Orlando, Florida
Post
Some of us Atari ST enthusiasts wish to have GameBase support for 'compilation disks' and alternate versions, as well as having more data columns in the game listing.
http://www.atari-forum.com/viewtopic.php?f=40&t=13016
We have been considering modifying the GameBase 1.2 source to achieve this. However, since you are creating a new version in .Net, I would prefer to avoid having two versions of GameBase.
Is there any chance of adding these features to your version? I am a VB programmer and I am more than willing to help with this project.
Thanks,
Patch
http://www.atari-forum.com/viewtopic.php?f=40&t=13016
We have been considering modifying the GameBase 1.2 source to achieve this. However, since you are creating a new version in .Net, I would prefer to avoid having two versions of GameBase.
Is there any chance of adding these features to your version? I am a VB programmer and I am more than willing to help with this project.
Thanks,
Patch
Return to “The GameBase Frontend”
Who is online
Users browsing this forum: No registered users and 8 guests