Castle Paradox

[Hieran_Del8]

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...

[Bob the Hamster]

[TMC]

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.

[Hieran_Del8]

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.

[Uncommon]

[Hieran_Del8]

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.

[TMC]

[Bob the Hamster]

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.

[TMC]

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."

[Hieran_Del8]

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?

[Bob the Hamster]

[Hieran_Del8]

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.

[Inferior Minion]

[TMC]

[Hieran_Del8]

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.

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.