[Ohrrpgce] On Data Mismanagement

[Keith Gable]

Hey guys,

I'm in a class where we're learning C++ data structures. I've been thinking
of some useful dataset I can work on to help make sure I know what I'm
doing. Then it hit me -- you guys are still loading .RPG files from
FreeBasic! :) So, I'm wondering

1) How useful would a native code lump/unlump library be to OHRRPGCE?
Preferably, I don't want to mess with underlying implementation of stuff
right now (so -- basically, just extract lumps into memory and such). So,
you could call it liblump.so/lump.dll or something like that. Later, if it's
useful, I could try for a librpgfile.so/rpgfile.dll that does all of that
underlying parsing.

2) Does FreeBasic support C++'s ABI, or does it only support C?

--
Keith Gable
Lead Programmer / Project Leader
The Ignition Project 

[Ask me how you can get a free Gmail account - Now with Google Chat!]
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Ralph Versteegen]

On 2/13/07, Keith Gable <[EMAIL PROTECTED]> wrote:
> Hey guys,
>
> I'm in a class where we're learning C++ data structures. I've been thinking
> of some useful dataset I can work on to help make sure I know what I'm
> doing. Then it hit me -- you guys are still loading .RPG files from
> FreeBasic! :) So, I'm wondering

Huh?

>
> 1) How useful would a native code lump/unlump library be to OHRRPGCE?
> Preferably, I don't want to mess with underlying implementation of stuff
> right now (so -- basically, just extract lumps into memory and such). So,
> you could call it liblump.so/lump.dll or something like that. Later, if it's
> useful, I could try for a librpgfile.so/rpgfile.dll that does all of that
> underlying parsing.
>

What do you mean by native code?

Well, that sort of library would be useful to programs which access
RPG files. I tried to make a lump.dll for Fyre for VB, but I don't
think he got it working - VB seems to require special activex dlls or
something.

Have a look at OHR++, it includes unlumping to memory and a (nearly
finished?) RPG file loader.

> 2) Does FreeBasic support C++'s ABI, or does it only support C?
>

Only C. See Mike's wrapper for the audiere library.
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Keith Gable]

On 2/12/07, Ralph Versteegen <[EMAIL PROTECTED]> wrote:
> On 2/13/07, Keith Gable <[EMAIL PROTECTED]> wrote:
> > Hey guys,
> >
> > I'm in a class where we're learning C++ data structures. I've been thinking
> > of some useful dataset I can work on to help make sure I know what I'm
> > doing. Then it hit me -- you guys are still loading .RPG files from
> > FreeBasic! :) So, I'm wondering
>
> Huh?

It's my understanding that FreeBasic is like VB in that it's compiled
to "fake" code and is then executed by an interpreter. So, using a C
library to do this will be faster. If it's not, then it's really the
same either way... :)


>
> >
> > 1) How useful would a native code lump/unlump library be to OHRRPGCE?
> > Preferably, I don't want to mess with underlying implementation of stuff
> > right now (so -- basically, just extract lumps into memory and such). So,
> > you could call it liblump.so/lump.dll or something like that. Later, if it's
> > useful, I could try for a librpgfile.so/rpgfile.dll that does all of that
> > underlying parsing.
> >
>
> What do you mean by native code?

Again, I understand that FreeBasic is interpreted. If not, nevermind :)

>
> Well, that sort of library would be useful to programs which access
> RPG files. I tried to make a lump.dll for Fyre for VB, but I don't
> think he got it working - VB seems to require special activex dlls or
> something.

DLLs work fine. You have to use Declare Function. Something like this:

In C:
int function_name(int &var1, int var2);

In VB:
Declare Function function_name Lib "dllname.dll" (ByRef var1 As
Integer, ByVal var2 As Integer) As Integer

If you actually want to associate the DLL with the project, it has to
be an ActiveX DLL. It's easier to do it using Declare Function. Or,
option #2 is to write a .ocx (ActiveX Control) in VB that executes
stuff in the DLL and then have VB users use the VB OCX. Slower, but
hey, it's VB6. :)

>
> Have a look at OHR++, it includes unlumping to memory and a (nearly
> finished?) RPG file loader.

Ahh If there's already a project, nevermind! :)

>
> > 2) Does FreeBasic support C++'s ABI, or does it only support C?
> >
>
> Only C. See Mike's wrapper for the audiere library.

Ouch. Nobody supports the C++ ABI except those coding in C++ -_-.

-- 
Keith Gable
Lead Programmer / Project Leader
The Ignition Project 

[Ask me how you can get a free Gmail account - Now with Google Chat!]
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Ralph Versteegen]

On 2/13/07, Keith Gable <[EMAIL PROTECTED]> wrote:
> On 2/12/07, Ralph Versteegen <[EMAIL PROTECTED]> wrote:
> > On 2/13/07, Keith Gable <[EMAIL PROTECTED]> wrote:
> > > Hey guys,
> > >
> > > I'm in a class where we're learning C++ data structures. I've been 
> > > thinking
> > > of some useful dataset I can work on to help make sure I know what I'm
> > > doing. Then it hit me -- you guys are still loading .RPG files from
> > > FreeBasic! :) So, I'm wondering
> >
> > Huh?
>
> It's my understanding that FreeBasic is like VB in that it's compiled
> to "fake" code and is then executed by an interpreter. So, using a C
> library to do this will be faster. If it's not, then it's really the
> same either way... :)
>

Oh, no, it's compiled! It's slower than C, but only because the
compiler is no where near as advanced at optimisation as compilers
like GCC - something which will hopefully change in the future.

Sure, unlumping speed could be improved, especially by not unlumping
at all (instead keep offsets to each lump) - which has been suggested
and was rejected at the time because of memory constraints - we were
still using QB.

>
> >
> > >
> > > 1) How useful would a native code lump/unlump library be to OHRRPGCE?
> > > Preferably, I don't want to mess with underlying implementation of stuff
> > > right now (so -- basically, just extract lumps into memory and such). So,
> > > you could call it liblump.so/lump.dll or something like that. Later, if 
> > > it's
> > > useful, I could try for a librpgfile.so/rpgfile.dll that does all of that
> > > underlying parsing.
> > >
> >
> > What do you mean by native code?
>
> Again, I understand that FreeBasic is interpreted. If not, nevermind :)
>
> >
> > Well, that sort of library would be useful to programs which access
> > RPG files. I tried to make a lump.dll for Fyre for VB, but I don't
> > think he got it working - VB seems to require special activex dlls or
> > something.
>
> DLLs work fine. You have to use Declare Function. Something like this:
>
> In C:
> int function_name(int &var1, int var2);
>
> In VB:
> Declare Function function_name Lib "dllname.dll" (ByRef var1 As
> Integer, ByVal var2 As Integer) As Integer
>
> If you actually want to associate the DLL with the project, it has to
> be an ActiveX DLL. It's easier to do it using Declare Function. Or,
> option #2 is to write a .ocx (ActiveX Control) in VB that executes
> stuff in the DLL and then have VB users use the VB OCX. Slower, but
> hey, it's VB6. :)

Maybe. But I don't have a copy of VB.NET to try it out with, I only
tested my dll with FB.

>
> >
> > Have a look at OHR++, it includes unlumping to memory and a (nearly
> > finished?) RPG file loader.
>
> Ahh If there's already a project, nevermind! :)
>
> >
> > > 2) Does FreeBasic support C++'s ABI, or does it only support C?
> > >
> >
> > Only C. See Mike's wrapper for the audiere library.
>
> Ouch. Nobody supports the C++ ABI except those coding in C++ -_-.
>
> --
> Keith Gable
> Lead Programmer / Project Leader
> The Ignition Project 
>
> [Ask me how you can get a free Gmail account - Now with Google Chat!]
> ___
> ohrrpgce mailing list
> ohrrpgce@lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Mike Caron]

On 2/12/07, Ralph Versteegen <[EMAIL PROTECTED]> wrote:
> On 2/13/07, Keith Gable <[EMAIL PROTECTED]> wrote:
> > On 2/12/07, Ralph Versteegen <[EMAIL PROTECTED]> wrote:
> > > On 2/13/07, Keith Gable <[EMAIL PROTECTED]> wrote:
> > > > Hey guys,
> > > >
> > > > I'm in a class where we're learning C++ data structures. I've been 
> > > > thinking
> > > > of some useful dataset I can work on to help make sure I know what I'm
> > > > doing. Then it hit me -- you guys are still loading .RPG files from
> > > > FreeBasic! :) So, I'm wondering
> > >
> > > Huh?
> >
> > It's my understanding that FreeBasic is like VB in that it's compiled
> > to "fake" code and is then executed by an interpreter. So, using a C
> > library to do this will be faster. If it's not, then it's really the
> > same either way... :)
> >
>
> Oh, no, it's compiled! It's slower than C, but only because the
> compiler is no where near as advanced at optimisation as compilers
> like GCC - something which will hopefully change in the future.

Yes, especially when it starts to use GCC as the backend :)

> Sure, unlumping speed could be improved, especially by not unlumping
> at all (instead keep offsets to each lump) - which has been suggested
> and was rejected at the time because of memory constraints - we were
> still using QB.

This coming from someone who limited the script buffer to 256kb? What
you're talking about is loading the entire RPG into memory. If not,
then you're not gaining anything by reading directly from the RPG
except disk space, and losing the ability to muck with the lumps on
the fly.

> > > > 1) How useful would a native code lump/unlump library be to OHRRPGCE?
> > > > Preferably, I don't want to mess with underlying implementation of stuff
> > > > right now (so -- basically, just extract lumps into memory and such). 
> > > > So,
> > > > you could call it liblump.so/lump.dll or something like that. Later, if 
> > > > it's
> > > > useful, I could try for a librpgfile.so/rpgfile.dll that does all of 
> > > > that
> > > > underlying parsing.
> > > >
> > >
> > > What do you mean by native code?
> >
> > Again, I understand that FreeBasic is interpreted. If not, nevermind :)

No, not at all. It's very much compiled.

> > > Well, that sort of library would be useful to programs which access
> > > RPG files. I tried to make a lump.dll for Fyre for VB, but I don't
> > > think he got it working - VB seems to require special activex dlls or
> > > something.
> >
> > DLLs work fine. You have to use Declare Function. Something like this:
> >
> > In C:
> > int function_name(int &var1, int var2);
> >
> > In VB:
> > Declare Function function_name Lib "dllname.dll" (ByRef var1 As
> > Integer, ByVal var2 As Integer) As Integer
> >
> > If you actually want to associate the DLL with the project, it has to
> > be an ActiveX DLL. It's easier to do it using Declare Function. Or,
> > option #2 is to write a .ocx (ActiveX Control) in VB that executes
> > stuff in the DLL and then have VB users use the VB OCX. Slower, but
> > hey, it's VB6. :)
>
> Maybe. But I don't have a copy of VB.NET to try it out with, I only
> tested my dll with FB.

VB.NET != Visual Basic. VB6 uses ActiveX files, but VB.NET uses .NET
assemblies. Wholly different concepts, implementations, and uses.

> > > Have a look at OHR++, it includes unlumping to memory and a (nearly
> > > finished?) RPG file loader.
> >
> > Ahh If there's already a project, nevermind! :)
> >
> > >
> > > > 2) Does FreeBasic support C++'s ABI, or does it only support C?

As I've said before, FreeBasic is C with a different syntax.

> > > Only C. See Mike's wrapper for the audiere library.

Written under duress, and with difficulty.

> > Ouch. Nobody supports the C++ ABI except those coding in C++ -_-.

Hmm, wonder why? That said, FB is actively working towards supporting
C++'s name-mangling and whatnot, for binary compatability with
existing APIs (What is an ABI? I'm not a C++ coder, so I may be
missing something)

-- 
Mike Caron
Final Fantasy Q
http://finalfantasyq.com
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Keith Gable]

-snip-
> This coming from someone who limited the script buffer to 256kb? What
> you're talking about is loading the entire RPG into memory. If not,
> then you're not gaining anything by reading directly from the RPG
> except disk space, and losing the ability to muck with the lumps on
> the fly.

I think this would be a Good Thing(TM), with memory not at a premium
anymore. The main thing is that lumps could be manipulated as raw data
structures.


> No, not at all. It's very much compiled.
>

Ahhh...


> VB.NET != Visual Basic. VB6 uses ActiveX files, but VB.NET uses .NET
> assemblies. Wholly different concepts, implementations, and uses.
>

You are very correct. VB.NET requires .NET, which makes it inherently
suck. VB6 was based on the QB language family rather than some subset
of C# and VB6 like VB.NET is. It's also a lot closer to hardware and
lets you do ... interesting things.

>
> As I've said before, FreeBasic is C with a different syntax.
>

I see.

> Hmm, wonder why? That said, FB is actively working towards supporting
> C++'s name-mangling and whatnot, for binary compatability with
> existing APIs (What is an ABI? I'm not a C++ coder, so I may be
> missing something)
>

ABI - Application Binary (or Binding) Interface.

Basically. All C++ apps have to speak the same ABI to use eachother.
Think basically like different versions of msvbvm??.dll or
msvcrt??.dll.

> --
> Mike Caron
> Final Fantasy Q
> http://finalfantasyq.com
> ___
> ohrrpgce mailing list
> ohrrpgce@lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>


-- 
Keith Gable
Lead Programmer / Project Leader
The Ignition Project 

[Ask me how you can get a free Gmail account - Now with Google Chat!]
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Bob the Hamster]

On Mon, Feb 12, 2007 at 09:11:23PM -0600, Keith Gable wrote:
> -snip-
> > This coming from someone who limited the script buffer to 256kb? What
> > you're talking about is loading the entire RPG into memory. If not,
> > then you're not gaining anything by reading directly from the RPG
> > except disk space, and losing the ability to muck with the lumps on
> > the fly.
> 
> I think this would be a Good Thing(TM), with memory not at a premium
> anymore. The main thing is that lumps could be manipulated as raw data
> structures.

I would not advocate loading into memory the whole RPG file. For most 
lumps, the speed improvement would be insignifigant.

The best way to determine which lumps should be kept in memory (and 
indeed which performance optimizations of ANY kind are appropriate) is 
with a profiling tool. Profile to see where the slow places actually 
are-- don't guess.

I myself have only recently learned this lesson, but now that I know it, 
I wish I had learned it... oh... back in 1998 (Help me, John Titor!)

---
Bob the Hamster
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Michael Kidder]

.NET doesn't suck. I'm suprised people would hate it, since it's
fairly easy to port a .NET program to Mono and run it on Linux / OSX.
An example of a great .NET program is Paint.NET (
http://www.getpaint.net ) which is being ported to Linux/Mono by
someone.

Of note, any programming language or program I tried to load the DLL
in didn't like it; Game Maker (which is written in Delphi) gave the
vague error of "Error Loading DLL". The exact error from Visual Basic
.NET was "no such entry point" for the function I tried to load with
the following code:

Declare Sub unlump Lib "unlumpdll" (ByRef lump$, ByRef ulpath$)

There's also an awesome reason: Visual Basic 6 costs money. Visual
Basic 2005 is free and available from MS at
http://msdn.microsoft.com/vstudio/express/ , so I'll die of old age
before I ever attempt to get VB6.

Either way, a DLL with general functions would be great since everyone
making external programs to the OHR wouldn't have to re-invent the
wheel every single time, and is a lot more flexible for people that
don't want to be forced to use the GPL by copying the unlump code from
the source.

On 2/12/07, Bob the Hamster <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 12, 2007 at 09:11:23PM -0600, Keith Gable wrote:
> > -snip-
> > > This coming from someone who limited the script buffer to 256kb? What
> > > you're talking about is loading the entire RPG into memory. If not,
> > > then you're not gaining anything by reading directly from the RPG
> > > except disk space, and losing the ability to muck with the lumps on
> > > the fly.
> >
> > I think this would be a Good Thing(TM), with memory not at a premium
> > anymore. The main thing is that lumps could be manipulated as raw data
> > structures.
>
> I would not advocate loading into memory the whole RPG file. For most
> lumps, the speed improvement would be insignifigant.
>
> The best way to determine which lumps should be kept in memory (and
> indeed which performance optimizations of ANY kind are appropriate) is
> with a profiling tool. Profile to see where the slow places actually
> are-- don't guess.
>
> I myself have only recently learned this lesson, but now that I know it,
> I wish I had learned it... oh... back in 1998 (Help me, John Titor!)
>
> ---
> Bob the Hamster
> ___
> ohrrpgce mailing list
> ohrrpgce@lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Mike Caron]

On 2/12/07, Michael Kidder <[EMAIL PROTECTED]> wrote:
> .NET doesn't suck. I'm suprised people would hate it, since it's
> fairly easy to port a .NET program to Mono and run it on Linux / OSX.
> An example of a great .NET program is Paint.NET (
> http://www.getpaint.net ) which is being ported to Linux/Mono by
> someone.

Oh, I totally agree. VB.Net is awesome, and I've got a couple projects
in the werkz written in it (nothing OHR, but still.)

> Of note, any programming language or program I tried to load the DLL
> in didn't like it; Game Maker (which is written in Delphi) gave the
> vague error of "Error Loading DLL". The exact error from Visual Basic
> .NET was "no such entry point" for the function I tried to load with
> the following code:
>
> Declare Sub unlump Lib "unlumpdll" (ByRef lump$, ByRef ulpath$)

That would be be because the entry point isn't really "unlump". The
most likely entry point is "[EMAIL PROTECTED]". Try changing the declare to:

Declare Sub unlump Alias "[EMAIL PROTECTED]" Lib "unlumpdll" (ByRef lump$, 
ByRef ulpath$)

Alias might need to go after Lib, my VB6 is rusty.

> There's also an awesome reason: Visual Basic 6 costs money. Visual
> Basic 2005 is free and available from MS at
> http://msdn.microsoft.com/vstudio/express/ , so I'll die of old age
> before I ever attempt to get VB6.

VB6 has it's uses. It runs on older platforms, and is actually faster
than VB.Net (it runs in native code, rather than being run under the
Common Language Runtime). However, what you say is still true. That
said, I managed to acquire Visual Stuidio 2005 from a friends office,
so I can't really complain much.

> Either way, a DLL with general functions would be great since everyone
> making external programs to the OHR wouldn't have to re-invent the
> wheel every single time, and is a lot more flexible for people that
> don't want to be forced to use the GPL by copying the unlump code from
> the source.

Maybe I'll throw something together on the weekend. I'll see.

-- 
Mike Caron
Final Fantasy Q
http://finalfantasyq.com
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Keith Gable]

On 2/12/07, Michael Kidder <[EMAIL PROTECTED]> wrote:
> .NET doesn't suck. I'm suprised people would hate it, since it's
> fairly easy to port a .NET program to Mono and run it on Linux / OSX.

_Sort of_.

If it's command line, it'll run without modification. If you use a
GUI, have fun. It usually requires porting of some kind, and last I
read up on it, there was no good way to have a UI look correct on
every platform (basically: Qt gets it right, .NET doesn't, wxWidgets
fails, etc.)

If I cared about portability though, I'd use another language that's a
little bit more... well... flexible, like Ruby or Python or something.
Regardless of how much a standards body has to do with it, .NET will
always be a Microsoft baby. Until Microsoft open sources their .NET
platform, it will still be a Microsoft baby. Seriously, you don't
think of Java as coming from anyone except Sun, right? The same
concept applies. Yeah, it runs anywhere. Anywhere that there's a CLR.
And the only CLR that is the _real_ CLR is the Microsoft CLR. There is
no Microsoft CLR for Unix. However, Sun does make a JDK/JRE for Unix.

So, I'm not going to consider Unix a "supported" .NET platform until
Microsoft comes out with a CLR. Right now, running VB6 apps under Wine
is more stable and less prone to errors (when using a GUI).

> An example of a great .NET program is Paint.NET (
> http://www.getpaint.net ) which is being ported to Linux/Mono by
> someone.
>
> Of note, any programming language or program I tried to load the DLL
> in didn't like it; Game Maker (which is written in Delphi) gave the
> vague error of "Error Loading DLL". The exact error from Visual Basic
> .NET was "no such entry point" for the function I tried to load with
> the following code:
>
> Declare Sub unlump Lib "unlumpdll" (ByRef lump$, ByRef ulpath$)

DLLs have to use the StdCall calling procedure to work with VB (this
is obviously something I know nothing about as I've never written a
DLL...).

>
> There's also an awesome reason: Visual Basic 6 costs money.

Well, being as acquiring a CD is easy enough, feel free to use any of
my CD keys:
000-000
111-000
000-111
111-111 (I think this one works)

;)

> Visual
> Basic 2005 is free and available from MS at
> http://msdn.microsoft.com/vstudio/express/ , so I'll die of old age
> before I ever attempt to get VB6.

Or, you can join the cool kids club and use another, more Unixy
language. I mean, _everyone_ is doing it. :)

Seriously though. Learn Ruby or Python or something ^_^.

>
> Either way, a DLL with general functions would be great since everyone
> making external programs to the OHR wouldn't have to re-invent the
> wheel every single time, and is a lot more flexible for people that
> don't want to be forced to use the GPL by copying the unlump code from
> the source.




So, are you suggesting LGPL? :)

>
> On 2/12/07, Bob the Hamster <[EMAIL PROTECTED]> wrote:
> > On Mon, Feb 12, 2007 at 09:11:23PM -0600, Keith Gable wrote:
> > > -snip-
> > > > This coming from someone who limited the script buffer to 256kb? What
> > > > you're talking about is loading the entire RPG into memory. If not,
> > > > then you're not gaining anything by reading directly from the RPG
> > > > except disk space, and losing the ability to muck with the lumps on
> > > > the fly.
> > >
> > > I think this would be a Good Thing(TM), with memory not at a premium
> > > anymore. The main thing is that lumps could be manipulated as raw data
> > > structures.
> >
> > I would not advocate loading into memory the whole RPG file. For most
> > lumps, the speed improvement would be insignifigant.
> >
> > The best way to determine which lumps should be kept in memory (and
> > indeed which performance optimizations of ANY kind are appropriate) is
> > with a profiling tool. Profile to see where the slow places actually
> > are-- don't guess.
> >
> > I myself have only recently learned this lesson, but now that I know it,
> > I wish I had learned it... oh... back in 1998 (Help me, John Titor!)
> >
> > ---
> > Bob the Hamster
> > ___
> > ohrrpgce mailing list
> > ohrrpgce@lists.motherhamster.org
> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> >
> ___
> ohrrpgce mailing list
> ohrrpgce@lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>



-- 
Keith Gable
Lead Programmer / Project Leader
The Ignition Project 

[Ask me how you can get a free Gmail account - Now with Google Chat!]
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Michael Kidder]

For one:

People have had no trouble porting GUI based .NET programs to Linux. See here:
part 1
http://tirania.org/blog/archive/2006/May-19.html

part 2
http://tirania.org/blog/archive/2006/Dec-16-1.html

Two
Sorry, but I'd rather not use fake keys to register a program. Using
Visual Studio Express is both free -and- legal.


Three
I have already tried to learn Ruby and Python and hated both of them.
But I also don't lord my programming language of choice over other
people, because I'm one of those weird platform-agnostic
programminglanguage-agnostic persons that just use what works for me.
VB6 programs are not going to run well or natively under Vista. And
I'd rather learn how to port to Mono than make someone run WINE just
for a engine frontend. WINE is not very user friendly.

Four
No, the license I was thinking of was either "none at all" or "MIT
license". I like open source but despise the GPL.


On 2/12/07, Keith Gable <[EMAIL PROTECTED]> wrote:
> 
>
> On 2/12/07, Michael Kidder <[EMAIL PROTECTED]> wrote:
> > .NET doesn't suck. I'm suprised people would hate it, since it's
> > fairly easy to port a .NET program to Mono and run it on Linux / OSX.
>
> _Sort of_.
>
> If it's command line, it'll run without modification. If you use a
> GUI, have fun. It usually requires porting of some kind, and last I
> read up on it, there was no good way to have a UI look correct on
> every platform (basically: Qt gets it right, .NET doesn't, wxWidgets
> fails, etc.)
>
> If I cared about portability though, I'd use another language that's a
> little bit more... well... flexible, like Ruby or Python or something.
> Regardless of how much a standards body has to do with it, .NET will
> always be a Microsoft baby. Until Microsoft open sources their .NET
> platform, it will still be a Microsoft baby. Seriously, you don't
> think of Java as coming from anyone except Sun, right? The same
> concept applies. Yeah, it runs anywhere. Anywhere that there's a CLR.
> And the only CLR that is the _real_ CLR is the Microsoft CLR. There is
> no Microsoft CLR for Unix. However, Sun does make a JDK/JRE for Unix.
>
> So, I'm not going to consider Unix a "supported" .NET platform until
> Microsoft comes out with a CLR. Right now, running VB6 apps under Wine
> is more stable and less prone to errors (when using a GUI).
>
> > An example of a great .NET program is Paint.NET (
> > http://www.getpaint.net ) which is being ported to Linux/Mono by
> > someone.
> >
> > Of note, any programming language or program I tried to load the DLL
> > in didn't like it; Game Maker (which is written in Delphi) gave the
> > vague error of "Error Loading DLL". The exact error from Visual Basic
> > .NET was "no such entry point" for the function I tried to load with
> > the following code:
> >
> > Declare Sub unlump Lib "unlumpdll" (ByRef lump$, ByRef ulpath$)
>
> DLLs have to use the StdCall calling procedure to work with VB (this
> is obviously something I know nothing about as I've never written a
> DLL...).
>
> >
> > There's also an awesome reason: Visual Basic 6 costs money.
>
> Well, being as acquiring a CD is easy enough, feel free to use any of
> my CD keys:
> 000-000
> 111-000
> 000-111
> 111-111 (I think this one works)
>
> ;)
>
> > Visual
> > Basic 2005 is free and available from MS at
> > http://msdn.microsoft.com/vstudio/express/ , so I'll die of old age
> > before I ever attempt to get VB6.
>
> Or, you can join the cool kids club and use another, more Unixy
> language. I mean, _everyone_ is doing it. :)
>
> Seriously though. Learn Ruby or Python or something ^_^.
>
> >
> > Either way, a DLL with general functions would be great since everyone
> > making external programs to the OHR wouldn't have to re-invent the
> > wheel every single time, and is a lot more flexible for people that
> > don't want to be forced to use the GPL by copying the unlump code from
> > the source.
>
> 
>
>
> So, are you suggesting LGPL? :)
>
> >
> > On 2/12/07, Bob the Hamster <[EMAIL PROTECTED]> wrote:
> > > On Mon, Feb 12, 2007 at 09:11:23PM -0600, Keith Gable wrote:
> > > > -snip-
> > > > > This coming from someone who limited the script buffer to 256kb? What
> > > > > you're talking about is loading the entire RPG into memory. If not,
> > > > > then you're not gaining anything by reading directly from the RPG
> > > > > except disk space, and losing the ability to muck with the lumps on
> > > > > the fly.
> > > >
> > > > I think this would be a Good Thing(TM), with memory not at a premium
> > > > anymore. The main thing is that lumps could be manipulated as raw data
> > > > structures.
> > >
> > > I would not advocate loading into memory the whole RPG file. For most
> > > lumps, the speed improvement would be insignifigant.
> > >
> > > The best way to determine which lumps should be kept in memory (and
> > > indeed which performance optimizations of ANY kind are appropriate) is
> > > with a profiling tool. Profile to see where the slow places actually
>

Re: [Ohrrpgce] On Data Mismanagement

[Keith Gable]

On 2/13/07, Michael Kidder <[EMAIL PROTECTED]> wrote:
> For one:
>
> People have had no trouble porting GUI based .NET programs to Linux. See here:
> part 1
> http://tirania.org/blog/archive/2006/May-19.html
>
> part 2
> http://tirania.org/blog/archive/2006/Dec-16-1.html
>

This is for applications using Gtk#. That's fine. What about the other
98% of applications using Forms? The latest version of Mono draws its
own forms (it used to tell Wine to do it), which is fine.. except if
you want it to look like your native Gtk or Qt (that is, unless they
use Gtk to draw the forms). My point is that for the vast majority of
.NET apps, they're going to require porting of some kind. Porting that
is substantially hurt because of the lack of official support.
Ideally, you don't port at all -- it just works. Java Swing is like
this.

> Two
> Sorry, but I'd rather not use fake keys to register a program. Using
> Visual Studio Express is both free -and- legal.
>

They're not fake per se. They're valid mathematical mistakes. I
actually own VB6 through my school. I just prefer to use the all zeros
key for a couple reasons:
1) it works
2) it looks funny in the startup dialogs
3) it's rumored that the VB6 bytecompiler embeds a checksum of your
key in all EXEs built, so Microsoft can see if the EXE was built with
a pirated VB6 or not. Using this key allows you to give Microsoft the
finger.

>
> Three
> I have already tried to learn Ruby and Python and hated both of them.

Most people love them. For me, coming from the QB/VB6 background, I
absolutely hate VB.NET and what Microsoft did to the language. I like
C#, but the fact that if Mono didn't exist, there'd be no
cross-platform support irks me.

The main reason I suggested Python/Ruby is because they work
everywhere. And if you need native code, you can use it (in Ruby, you
can actually write the code inline in your .rb files).

> But I also don't lord my programming language of choice over other
> people, because I'm one of those weird platform-agnostic
> programminglanguage-agnostic persons that just use what works for me.
> VB6 programs are not going to run well or natively under Vista.

Nothing runs well under Vista. Vista doesn't run well under Vista.
Case in point? There's a memory water main busted somewhere. It's
bigger than a leak. If you use Vista for a few days, you've leaked
about a gig of memory. Using Beryl in Gentoo, I leak about 100-200MB
(I'm sitting at 500MB right now and I've been up for about a week). I
heard that this leak is a feature related to prefetching, but I don't
like it at all if it is.

Also, there has to be a way to use Avalon from non-managed C++.
Otherwise, Microsoft is going to piss off Adobe and everyone else that
has huge applications written in non-managed C++ or C. And if there is
a way, there's a way to do it from VB6. And if someone makes a VB6
designer for Avalon-related crap, the language will live on into the
next decade. Because it works on everything (in this case, it'd only
work on XP+Vista, unless the Avalon designer automagically converted
the forms to be VB6 forms if Avalon isn't found...).

> And
> I'd rather learn how to port to Mono than make someone run WINE just
> for a engine frontend. WINE is not very user friendly.

Well. It's getting there. Most people who want user-friendliness use
CrossOver though.

>
> Four
> No, the license I was thinking of was either "none at all" or "MIT
> license". I like open source but despise the GPL.

I like the GPL. Then again, if I couldn't secure a way for people to
either share their modifications or don't modify my programs at all, I
wouldn't have open sourced it in the first place. I don't like the BSD
license for this reason -- anyone can take my code, use it, change it,
and screw me over. If I'm making an office suite, for example, all
Microsoft has to do is steal my code, put their name on it, and sell
it, and suddenly my work is now useless, because I now have to compete
against myself. Yes, they've done similar things before.

>
>
> On 2/12/07, Keith Gable <[EMAIL PROTECTED]> wrote:
> > 
> >
> > On 2/12/07, Michael Kidder <[EMAIL PROTECTED]> wrote:
> > > .NET doesn't suck. I'm suprised people would hate it, since it's
> > > fairly easy to port a .NET program to Mono and run it on Linux / OSX.
> >
> > _Sort of_.
> >
> > If it's command line, it'll run without modification. If you use a
> > GUI, have fun. It usually requires porting of some kind, and last I
> > read up on it, there was no good way to have a UI look correct on
> > every platform (basically: Qt gets it right, .NET doesn't, wxWidgets
> > fails, etc.)
> >
> > If I cared about portability though, I'd use another language that's a
> > little bit more... well... flexible, like Ruby or Python or something.
> > Regardless of how much a standards body has to do with it, .NET will
> > always be a Microsoft baby. Until Microsoft open sources their .NET
> > platform, it will still be a Microsoft baby. Seriously, you don't
> >

Re: [Ohrrpgce] On Data Mismanagement

[Simon Bradley]

On 2/13/07, Keith Gable <[EMAIL PROTECTED]> wrote:
> On 2/13/07, Michael Kidder <[EMAIL PROTECTED]> wrote:
> > Four
> > No, the license I was thinking of was either "none at all" or "MIT
> > license". I like open source but despise the GPL.
>
> I like the GPL. Then again, if I couldn't secure a way for people to
> either share their modifications or don't modify my programs at all, I
> wouldn't have open sourced it in the first place. I don't like the BSD
> license for this reason -- anyone can take my code, use it, change it,
> and screw me over. If I'm making an office suite, for example, all
> Microsoft has to do is steal my code, put their name on it, and sell
> it, and suddenly my work is now useless, because I now have to compete
> against myself. Yes, they've done similar things before.
>

I had an argument with a (linux-using) former colleague about this
once. I don't like copyleft licenses myself, since they are still
restrictive. My colleague claimed that MS had "stolen" the open source
BSD socket code, and that was why copyleft was good. My position was
that it had made MS's sockets work properly, which was, frankly, good
for everyone, and that was why copyleft was bad.

But anyway, none of that's really relevant, here.


> > > > On 2/12/07, Bob the Hamster <[EMAIL PROTECTED]> wrote:
> > > > > On Mon, Feb 12, 2007 at 09:11:23PM -0600, Keith Gable wrote:
> > > > > > -snip-
> > > > > > > This coming from someone who limited the script buffer to 256kb? 
> > > > > > > What
> > > > > > > you're talking about is loading the entire RPG into memory. If 
> > > > > > > not,
> > > > > > > then you're not gaining anything by reading directly from the RPG
> > > > > > > except disk space, and losing the ability to muck with the lumps 
> > > > > > > on
> > > > > > > the fly.
> > > > > >
> > > > > > I think this would be a Good Thing(TM), with memory not at a premium
> > > > > > anymore. The main thing is that lumps could be manipulated as raw 
> > > > > > data
> > > > > > structures.
> > > > >
> > > > > I would not advocate loading into memory the whole RPG file. For most
> > > > > lumps, the speed improvement would be insignifigant.
> > > > >
> > > > > The best way to determine which lumps should be kept in memory (and
> > > > > indeed which performance optimizations of ANY kind are appropriate) is
> > > > > with a profiling tool. Profile to see where the slow places actually
> > > > > are-- don't guess.
> > > > >
> > > > > I myself have only recently learned this lesson, but now that I know 
> > > > > it,
> > > > > I wish I had learned it... oh... back in 1998 (Help me, John Titor!)
> > > > >

Er, I think I've lost at least one layer of atribution, there, but hey.

The advantage of not unlumping is, well, not unlumping. The time saved
is the initial read-through of the rpg file and writing all the
smaller files. It would at least be spread out a little if we used
lazy unlumping, and only wrote files as we needed them, but at that
point the speed penalties might be occurring at a worse time. Is a big
pause at the start better than a small pause in the middle?

Simon

> > > > > ---
> > > > > Bob the Hamster
> > > > > ___
> > > > > ohrrpgce mailing list
> > > > > ohrrpgce@lists.motherhamster.org
> > > > > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> > > > >
> > > > ___
> > > > ohrrpgce mailing list
> > > > ohrrpgce@lists.motherhamster.org
> > > > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> > > >
> > >
> > >
> > >
> > > --
> > > Keith Gable
> > > Lead Programmer / Project Leader
> > > The Ignition Project 
> > >
> > > [Ask me how you can get a free Gmail account - Now with Google Chat!]
> > > ___
> > > ohrrpgce mailing list
> > > ohrrpgce@lists.motherhamster.org
> > > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> > >
> > ___
> > ohrrpgce mailing list
> > ohrrpgce@lists.motherhamster.org
> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> >
>
>
> --
> Keith Gable
> Lead Programmer / Project Leader
> The Ignition Project 
>
> [Ask me how you can get a free Gmail account - Now with Google Chat!]
> ___
> ohrrpgce mailing list
> ohrrpgce@lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Bob the Hamster]

> 
> Er, I think I've lost at least one layer of atribution, there, but hey.
> 
> The advantage of not unlumping is, well, not unlumping. The time saved
> is the initial read-through of the rpg file and writing all the
> smaller files. It would at least be spread out a little if we used
> lazy unlumping, and only wrote files as we needed them, but at that
> point the speed penalties might be occurring at a worse time. Is a big
> pause at the start better than a small pause in the middle?
> 
> Simon
> 

Actually, we already have quite decent support for pre-unlumped files.

All we are missing is the ability for a renamed copy of game.exe to 
autoload a similarly named .rpgdir in the same folder.

---
Bob the Hamster
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Re: [Ohrrpgce] On Data Mismanagement

[Ralph Versteegen]

On 2/14/07, Bob the Hamster <[EMAIL PROTECTED]> wrote:
> >
> > Er, I think I've lost at least one layer of atribution, there, but hey.
> >
> > The advantage of not unlumping is, well, not unlumping. The time saved
> > is the initial read-through of the rpg file and writing all the
> > smaller files. It would at least be spread out a little if we used
> > lazy unlumping, and only wrote files as we needed them, but at that
> > point the speed penalties might be occurring at a worse time. Is a big
> > pause at the start better than a small pause in the middle?
> >
> > Simon
> >
>
> Actually, we already have quite decent support for pre-unlumped files.
>
> All we are missing is the ability for a renamed copy of game.exe to
> autoload a similarly named .rpgdir in the same folder.
>
> ---
> Bob the Hamster

Oh, really? I didn't notice. Someone ought to do that then ;)
___
ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org