Castle Paradox Forum Index Castle Paradox

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 Gamelist   Review List   Song List   All Journals   Site Stats   Search Gamelist   IRC Chat Room

Porting to c++, freebasic constructors?
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    Castle Paradox Forum Index -> The Arcade
View previous topic :: View next topic  
Author Message
Hieran_Del8




Joined: 23 Jan 2009
Posts: 18

PostPosted: Fri Jan 23, 2009 1:23 pm    Post subject: Porting to c++, freebasic constructors? Reply with quote

I started converting the freebasic code to c++, and ran across a few lines of confusing code, such as:

TYPE something
someValue(0) as integer
END TYPE

or

TYPE somethingElse
someValue(999999)
ENDTYPE

I at first thought they were array declarations, though I suppose DIM statements would reveal that. Are the parentheses a constructor, or an array declaration?
If a constructor, what do array declarations specifically appear as? Else, how are they to be interpreted?

EDIT:
I know what TYPE and ENDTYPE mean--it's the someValue(0) that I don't understand. If the statement read
TYPE something
someValue as integer
ENDTYPE
then it'd be understood as an integer in a structure. But those parantheses...
Back to top
View user's profile Send private message Visit poster's website
Bob the Hamster
OHRRPGCE Developer




Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)

PostPosted: Fri Jan 23, 2009 9:50 pm    Post subject: Re: Porting to c++, freebasic constructors? Reply with quote

Hieran_Del8 wrote:
I started converting the freebasic code to c++, and ran across a few lines of confusing code, such as:


Have you talked to TeeEmCee about this? He's done some work on a c++ conversion too. Maybe you should compare notes.

Hieran_Del8 wrote:

someValue(0) as integer


that is an array with just a single integer element.

Hieran_Del8 wrote:

someValue(999999)


That is a large array of the default type. The default type is set to Integers with the DEFINT A-Z command at the beginning of the file.

Hieran_Del8 wrote:

I at first thought they were array declarations, though I suppose DIM statements would reveal that. Are the parentheses a constructor, or an array declaration?
If a constructor, what do array declarations specifically appear as? Else, how are they to be interpreted?


Yes, they are array declarations, but because they are in TYPE blocks you will not find a corresponding DIM

The latest version of FreeBasic does support constructors, but we don't use any of them at all.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
TMC
On the Verge of Insanity




Joined: 05 Apr 2003
Posts: 3230
Location: Matakana

PostPosted: Sun Jan 25, 2009 9:19 pm    Post subject: Re: Porting to c++, freebasic constructors? Reply with quote

Hi. I was planning to write a FB to C++ converter, but haven't done any work on the converter yet, just some C++ classes for FB strings and arrays. So why are you translating it, is there some platform you want to port to?

I'd post on the mailing list instead of Castle Paradox! I'm sure everyone who can help you with engine development reads the mailinglist.

James Paige wrote:
Hieran_Del8 wrote:

someValue(999999)


That is a large array of the default type. The default type is set to Integers with the DEFINT A-Z command at the beginning of the file.


DEFINT still does something? I thought it stopped functioning long ago. I'd prefer not using it.

Anyway, you're looking at
Code:

TYPE ScriptCommand
  kind as integer
  value as integer
  argc as integer
  args(999999) as integer
END TYPE


The equivalent C99 is

Code:

struct ScriptCommand {
  int kind;
  int value;
  int argc;
  int args[];
};


If you're not using C99, any array size will do.
_________________
"It is so great it is insanely great."
Back to top
View user's profile Send private message Send e-mail MSN Messenger
Hieran_Del8




Joined: 23 Jan 2009
Posts: 18

PostPosted: Mon Jan 26, 2009 12:26 pm    Post subject: Reply with quote

Ah, thank you James! That makes a lot of sense. Furthermore, I forgot that array declarations include 0 as a possible value, so someValue(5) means 6 entries. (In c++ someValue[5] means 5 entries.)

I will contact TeeEmCee, I suppose through the mailing list.

The Mad Cacti: I was interested in porting the system so that it'd support DirectX 9.0c graphics. (I haven't begun 10 yet...) I thought it might benefit from the graphic accelerations, and I'd like to enable post-process effects, etc. HLSL is a lot easier for that sort of thing imo.

Granted, this loses support for other platforms besides windows, but it would be cool. (This means extended support for movie playing and capturing, sound, font, sprite, textures, and more.)

A friend showed me Jame's custom editor about 10 years ago, and I thought it was awesome. I wanted to build something like that too (I also was QBasic at first). Now I've learned a bit since then (pun intended), and I want to help extend a community that inspired me.
Back to top
View user's profile Send private message Visit poster's website
Uncommon
His legend will never die




Joined: 10 Mar 2003
Posts: 2506

PostPosted: Mon Jan 26, 2009 2:06 pm    Post subject: Reply with quote

Hieran_Del8 wrote:
I will contact TeeEmCee, I suppose through the mailing list.

For simplicity's sake, I feel I should inform you that TeeEmCee is the phonetic spelling of the acronym TMC, which stands for The Mad Cacti.
You need look no further than this very thread.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address
Hieran_Del8




Joined: 23 Jan 2009
Posts: 18

PostPosted: Mon Jan 26, 2009 6:01 pm    Post subject: Reply with quote

L!
O!
L!
Wow! That was hilarious. Well, nice to make your acquaintance, all.

I've signed up for the mailing list. TMC, what design are you planning for the FB to c++ converter? I'd like to help. I've been building a script parser that converts script (including user made structs and functions) into c++ code. Right now it only converts to usable code at runtime, a little heavy on the cpu. That can be adapted, though.
Back to top
View user's profile Send private message Visit poster's website
TMC
On the Verge of Insanity




Joined: 05 Apr 2003
Posts: 3230
Location: Matakana

PostPosted: Tue Jan 27, 2009 7:57 am    Post subject: Reply with quote

Hieran_Del8 wrote:
I've signed up for the mailing list. TMC, what design are you planning for the FB to c++ converter? I'd like to help.


I've written C++ template classes to wrap FB's strings and arrays (using actual FB strings and arrays and calls to the FB runtime library (written in C)). With those two features out of the way, the rest of FB should be translatable nearly directly to C++ except:
* the preprocessor works differently. In FB, preprocessor directives aren't preprocessed, they're processed by the parser.
* variables don't have to be declared. It should be easy to automatically generate the declarations
* GOSUB/RETRACE aren't FB keywords in the OHR sources, they're implemented using assembly hackery. I'm not sure the same would work in C++.

A couple of users on the FreeBASIC forums have been working on writing formal grammars for FB. So why not use these if we can? (freebasic.net seems to be down at the moment)
FreeBASIC grammar (extracted from the FreeBASIC sources) (skip to McLovin's comment)
FreeBASIC Grammar Part I
However, I've never used a formal grammar or compiler compiler before. Have you? Of course, the formal grammar could be more work than it saves. If you have a little experience with parsers, that's great.


Hieran_Del8 wrote:
I've been building a script parser that converts script (including user made structs and functions) into c++ code. Right now it only converts to usable code at runtime, a little heavy on the cpu. That can be adapted, though.


Script parser? Are you talking about speeding up HamsterSpeak scripts? That's cool. I once (~3 years back) started on a similar HS to C converter. Lost interest. Anyway, the biggest problem is dealing with wait commands - especially if the Plan for script multitasking is implemented. I think I was going to use something like setjmp/longjmp or microthreads.

What do you mean by runtime, it translates, compiles, and executes the script when it's run? :)

The interpreter is still very slow, but I plan to rewrite it (soon, honest, I've started) to support dynamic typing (rough plan for dynamic types in HamsterSpeak) and be much faster. With dynamic typing a HS-to-C++ translator will probably become very difficult and not much faster than the interpreter without static type analysis.


Quote:
The Mad Cacti: I was interested in porting the system so that it'd support DirectX 9.0c graphics. (I haven't begun 10 yet...) I thought it might benefit from the graphic accelerations, and I'd like to enable post-process effects, etc. HLSL is a lot easier for that sort of thing imo.

Granted, this loses support for other platforms besides windows, but it would be cool. (This means extended support for movie playing and capturing, sound, font, sprite, textures, and more.


DirectX10 is beyond what I think we were hoping for :) but hardware acceleration would be cool and Mode 7 style effects, transparency, higher colour depth and weather effects are often requested.

I'd like to switch back to SDL as the default graphics backend. Just using that to its full capabilities would mean a lot, and it allows very easy use of OpenGL. I'm aiming towards being able to run on pretty much any handheld with a 320x200 screen (but probably some games will always be too intensive).

You could go out and write a graphics backend in C++ using DX today if you wanted without porting the rest of the engine, and I'm sure it'd be welcome. But we'd definitely want everything but unimportant/unused features supported on all platforms. However right now the graphics backends don't really do much anyway: the drawing code is in the wrong place.

But the biggest problem with improving the graphical capabilities of the engine isn't the language or the graphics library, but the RPG file format, all the existing inflexible graphics code (which used to be REALLY BAD but has been much improved to just plain bad) including builtin menus in Game (which wouldn't yet handle something like non-8x8 font) and editors in Custom. Script commands are the easiest way to add features like that.
_________________
"It is so great it is insanely great."
Back to top
View user's profile Send private message Send e-mail MSN Messenger
Bob the Hamster
OHRRPGCE Developer




Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)

PostPosted: Tue Jan 27, 2009 9:01 am    Post subject: Reply with quote

Speaking of hardware acceleration, when SDL 1.3/2.0 matures enough we can switch to that, and get hardware accel without giving up cross-platform compat.

The biggest reason that a C++ conversion would be interesting to me is that it would provide much higher cross-platform compatibility, since most platforms and architectures already have C++ compilers.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
TMC
On the Verge of Insanity




Joined: 05 Apr 2003
Posts: 3230
Location: Matakana

PostPosted: Tue Jan 27, 2009 9:12 am    Post subject: Reply with quote

Huh? SDL 1.2 already provides hardware acceleration when possible (using DX 5 under Windows, I believe). What I'm looking forward to is multiple windows.
_________________
"It is so great it is insanely great."
Back to top
View user's profile Send private message Send e-mail MSN Messenger
Hieran_Del8




Joined: 23 Jan 2009
Posts: 18

PostPosted: Tue Jan 27, 2009 10:59 am    Post subject: Reply with quote

TMC:
Originally, I was designing a QBasic to c++ direct converter, where the qbasic codes would run in a windowed, directx environment in c++. I was hoping to finish a translator that would run the qbasic code as a script at runtime. The templates for reading a basic file and storing "phrases" of commands and declarations was nearing completion. I didn't finish the translator, though. I moved on about 3 months ago.

Initially, the thought occurred to use this to convert the FB code directly to output header and source files. However, that will likely get very messy. I propose a complete rewrite of the code in c++. (It shouldn't take too long. We just need to establish what the main classes are.) This offers a deluge of benefits, some of the foremost being cleaner code, object-oriented design, and support for infinite graphic animations and tilesets (well, close enough to infinite to not care).

To clarify about the script parser, "usable code at run-time" was a translation mechanism that would build dynamic functions, structures, and variables during runtime for some events/calculations to be accomplished by the script. It wouldn't convert the script to c++ source code.

Since you mention it, I suppose the script parser could add ability to the HamsterSpeak scripts so that user made functions and structures would be valid.

Are you considering revising the rpg file format? Have you considered xml format? Are you up to determining what classes should exist in the c++ code?
Back to top
View user's profile Send private message Visit poster's website
Bob the Hamster
OHRRPGCE Developer




Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)

PostPosted: Tue Jan 27, 2009 11:47 am    Post subject: Reply with quote

Hieran_Del8 wrote:
... I propose a complete rewrite of the code in c++. (It shouldn't take too long. We just need to establish what the main classes are.)


This has been proposed, and indeed started at least twice. Not trying to discourage you, just saying it may be a bigger task than you think.

Hieran_Del8 wrote:
This offers a deluge of benefits, some of the foremost being cleaner code, object-oriented design, and support for infinite graphic animations and tilesets (well, close enough to infinite to not care).


The FreeBasic port already provides theoretical access to all of those things. A C++ port would not solve the really important questions of backwards compatibility. If you add support for infinite graphic animations, how do you make sure that the old finite graphic animations? What will the user-interface be for creating and managing more animations?

Hieran_Del8 wrote:
Are you considering revising the rpg file format? Have you considered xml format? Are you up to determining what classes should exist in the c++ code?


Yes, we have considered XML, but for the time being we have decided against it. There are some nice things about XML, but many of its benefts are negated by our backwards compatibility needs. There are some pretty in-depth discussions about XML and RPG format changes both on the Wiki and in the mailing list archives.

You might want to read RELOAD.

You might also want to check the mailing list archive for David Gower's work on ohrrpgce.py
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Hieran_Del8




Joined: 23 Jan 2009
Posts: 18

PostPosted: Tue Jan 27, 2009 4:23 pm    Post subject: Reply with quote

I understand it's a large undertaking. I've built editors before, completely rewriting them whenever an alternate method could be tried. I enjoy object-based and object-oriented design models, as upgrading them takes drastically less time.

I agree it is a very heavy task. But this is my passion. I enjoy the coding more than using the editor. It's kind of like a mechanic enjoying the inside of a car more than driving it. I have a drive to code.

How compatible do you intend the system?

Regarding infinite graphic animations, a simple vector of frame pointers would manage any size set. Each frame could contain a length of time to display before leaving the frame. What's your take?

Regarding a user interface for more animations, a timeline view may allow for more entries. What do you think?

The current backends could still be used for all the rendering. I propose to adjust the data management system, as well as tweak the user interface. I feel the backends should inherit functionality from an abstract class for maximum compatibility. The design could force all rendering to occur in addon modules (dlls, backends, etc.) through callbacks--not in the editor.

Should we start a class design list?

Btw, I don't know how to use the mail list.
Back to top
View user's profile Send private message Visit poster's website
Inferior Minion
Metric Ruler



Joined: 03 Jan 2003
Posts: 741
Location: Santa Barbara, CA

PostPosted: Tue Jan 27, 2009 5:36 pm    Post subject: Reply with quote

Hieran_Del8 wrote:
I understand it's a large undertaking. I've built editors before, completely rewriting them whenever an alternate method could be tried. I enjoy object-based and object-oriented design models, as upgrading them takes drastically less time.

I agree it is a very heavy task. But this is my passion. I enjoy the coding more than using the editor. It's kind of like a mechanic enjoying the inside of a car more than driving it. I have a drive to code.


I know exactly how you feel Big grin. My initial attempt to rewrite the OHR stems from the same desire. Up until I committed to completely rewriting the backend supporting this site, my development was progressing rather quickly. The codebase is now 1 year out of development, and changes to the RPG format may cause things to break, but here's my work thus far: http://ohrpp.castleparadox.com/

I was stumbling through battle code when I shifted focus to Castle Paradox exclusively (couldn't find the time to juggle work and 2 projects). I do have every intention of continuing development once the Castle Paradox overhaul gets to a more stable state.

The current code was running properly on Windows, Linux, and Mac OS X.

Regarding the mailing list, all you need to do is subscribe to the list here: http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Once you've subscribed, you will receive e-mails whenever someone sends something to the list. If you wish to send an e-mail to the list, just send the e-mail to ohrrpgce@lists.motherhamster.org.

Cheers,

~IM
_________________
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address MSN Messenger
TMC
On the Verge of Insanity




Joined: 05 Apr 2003
Posts: 3230
Location: Matakana

PostPosted: Tue Jan 27, 2009 11:57 pm    Post subject: Reply with quote

Hieran_Del8 wrote:
TMC:
Originally, I was designing a QBasic to c++ direct converter, where the qbasic codes would run in a windowed, directx environment in c++. I was hoping to finish a translator that would run the qbasic code as a script at runtime. The templates for reading a basic file and storing "phrases" of commands and declarations was nearing completion. I didn't finish the translator, though. I moved on about 3 months ago.


So it was an interpreter?

Hieran_Del8 wrote:
Initially, the thought occurred to use this to convert the FB code directly to output header and source files. However, that will likely get very messy.


Actually, like I said I think a line for line translation would be very close to the original without much added messiness. Of course, the code won't be better except in exceptional cases.

Hieran_Del8 wrote:
To clarify about the script parser, "usable code at run-time" was a translation mechanism that would build dynamic functions, structures, and variables during runtime for some events/calculations to be accomplished by the script. It wouldn't convert the script to c++ source code.

Since you mention it, I suppose the script parser could add ability to the HamsterSpeak scripts so that user made functions and structures would be valid.


You mean it worked in the same was your BASIC interpreter (if that's what it was?) I'm a bit lost.

Hieran_Del8 wrote:
Are you considering revising the rpg file format? Have you considered xml format? Are you up to determining what classes should exist in the c++ code?


We are continuously replacing bits of the RPG format as we get around to it. Maybe the biggest thing that needs replacing at the moment is the format for all the different graphics (sprites, tilesets, backdrops and fonts). A lot of Source#Development Plans depend on it (I count at least 5) and lots of others things we would like that aren't on that list.


Hieran_Del8 wrote:
How compatible do you intend the system?


100%. The ideal is that all OHR games ever made should work without significant bugs, with exception of those using a modified engine, but including those relying on bugs (such as Ends of the Earth) or on features of WIP builds that have since been changed (such as Missing). In fact some very old games don't seem to work properly, but that's something we should aim to fix. Wait, are you talking about a rewrite?

Hieran_Del8 wrote:
Regarding infinite graphic animations, a simple vector of frame pointers would manage any size set. Each frame could contain a length of time to display before leaving the frame. What's your take?


See below. However, what about attack animations which let you choose how to animate the attack frames.

Hieran_Del8 wrote:
Regarding a user interface for more animations, a timeline view may allow for more entries. What do you think?


It's not the plan currently on the wiki, but I'd like each spriteset to be a collection of different actions (like walk left, right for a walkabout, attack and use item for a hero) each with a flexible number of frames (of any size) and animation pattern. It could be a lot of frames to display. A timeline is an interesting idea.
_________________
"It is so great it is insanely great."
Back to top
View user's profile Send private message Send e-mail MSN Messenger
Hieran_Del8




Joined: 23 Jan 2009
Posts: 18

PostPosted: Wed Jan 28, 2009 8:18 pm    Post subject: Reply with quote

Inferior Minion:
Cheers! I understand what you mean about having to juggle multiple projects. I'm currently working on a class that renders movie files to a IDirect3DTexture9, and renders the audio stream to an application's XAudio2 interface. Essentially, this allows a movie to play on a surface in a directx environment, which can be wrapped around any model/surface. And the audio could appear to arrive to the listener from the correct 3d perspective. For instance, imagine a television model that really plays movies whenever the user activates it. For more info, look for me on http://www.d3dcoder.net/phpBB/index.php forums.

Btw, thanks for helping me use the mailing system. Wink

TMC:
Yes. It was an interpreter. I admit I never got the translator complete enough to attach it to the data management system, but if I revisit it, I'm afraid I'd rewrite it. I didn't build it with multiple processors in mind, but now I would. I'm holding off on doing so, though, as c++ is getting a new standard this year. This standard gives native support for thread handling, plus a few other template enhancements that I currently find useful.

In regards compatibility, I agree that 100% should be strived for. A conversion utility can be provided to "upgrade" the data to a compatible state.

However, I wanted to know what systems this should be compatible across, including Windows, Linux, MacOS, DOS, cell phones, internet, etc.

To be compatible, different derivations of certain abstract classes could allow for different system implementations (or perhaps communicating between processes (dlls) could address this).

If you're on the mailing list, please consider the proposed modules, including the Surface module, which would manage all graphic surfaces (and thus adapt the surface handling based on the source input, etc.) Please propose, strike, or recommend more modules to the system.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Castle Paradox Forum Index -> The Arcade All times are GMT - 8 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group