realbasic-plugins
[Top] [All Lists]

Re: Maybe a way to register global constants?

To: REALbasic Plugins <realbasic-plugins at lists dot realsoftware dot com>
Subject: Re: Maybe a way to register global constants?
From: Frank Condello <developer at chaoticbox dot com>
Date: Thu, 15 Dec 2005 17:56:01 -0500
Delivered-to: realbasic-plugins at lists dot realsoftware dot com
References: <3A710B42-C352-4D33-9B91-F04FC553B604 at sqlabs dot net> <CAC84461-C87A-4EEB-8388-73CEF234F8C8 at realsoftware dot com> <71CCFA99-4B1E-49C8-A846-03BB2AB99015 at sqlabs dot net> <95344E36-E288-4106-9D3B-AA1098E00369 at elfdata dot com>
On 15-Dec-05, at 5:09 PM, Theodore H. Smith wrote:

On 15 Dec 2005, at 21:15, Marco Bambini wrote:

On Dec 15, 2005, at 10:11 PM, Mars Saxman wrote:

On Dec 15, 2005, at 12:54 PM, Marco Bambini wrote:

I know that there isn't a way to add global constants inside a plugin so my idea is to extend the RealBasic class and just add to it the constants I need.

Why not just accept the way the system is designed to work and put your constants into a module?

Because I would like to reduce the time needed to convert C opengl code to RB. It should be nice if constants can be used as is, without the needs to append a moduleName. in each of them...

A few smart regexes should do the trick Marco. I've done this sort of thing before. You can convert one kind of listing into another, using some nice regexes.

If I know my GL headers, a simple case-sensitive search & replace will do it without no ill effects. The main problem I would have with this is that Rb GL code suddenly looks different than the standard implementation. You could always include an optional Rb module with "real" global constants to maintain readability however.

Also, really I wouldn't bother with the OpenGL. It's been done. It's been done maybe 8 years ago by xmath, and then by Doug Houlton, and a whole bunch of other people.

The old plugins are useless in the current IDEs/platforms, but there are some capable sets of declares available for free. That doesn't mean everything's covered, and Marco certainly has some useful stuff planned for this plugin. This was discussed at length on the Games NUG but the archives are down so I can't point you to the relevant articles ATM...

Eventually most people found that OpenGL while nice, doesn't make coding for 3D easy...

Some will argue that coding for 3D is *never* easy. You're right though, OpenGL is a low-level 3D API, but it's also a very popular 3D API, and many people coming from other languages are already familiar with it.

.. but to make a good game, it's really not simple.

Again, making a good game is *never* really simple :)

OpenGL is hard enough to build large systems out of what with it's OpenGL states and that, but then you need a whole extra layer of complexity due to having to jump through hoops to maintain speed.

It ain't so bad IMHO, but you do have to study up on the quirks of the API and target hardware to avoid slow paths.

Did you know that many of the best games, don't even use most of OpenGL's API??? They just write a whole TON of triangles into an OpenGLVertexArray (or whatever it's called),

True, but many crappy games do that too, vertex arrays have been standard fare for many years.

and dump the entire scene through one API call. Instead of getting OpenGL to do all the translation and processing, they do it themselves and use very little OpenGL at all. This is simply because the OpenGL API isn't the best designed for getting good gaming speed with modern games.

Not true at all! Before T&L cards were widely available (10 years ago!) people may have done they're own transforms in software but that's no longer the case. There are situations that still require CPU fallback paths on certain hardware (like per-vertex deformation) but more and more stuff happens on the GPU nowadays, and OpenGL provides accelerated APIs for just about anything you'd need. Check out a couple little games called DooM3 and Quake4 if ya don't beleive me ;)

Also, OpenGl doesn't offer you everything you need. You'll still some other code for things like space culling (Where objects that can't be seen don't get drawn). And then there's collision detection. OpenGL gives you no ability for collision detection... So you need to write a simple and extensible, yet fast framework for collision detection.

Unless you are an OpenGL and game master I wouldn't really bother making an OpenGL plugin.

It's clear you've misunderstood the intent and target audience of Marco's plugin. The plugin provides a convenient way to access the OpenGL API in RB, and is meant for current OpenGL programers or people wanting/willing to learn. If Marco called it "UberGameEnginePlugin" then your arguments would have merit, but as I see it, he's delivering a product as advertised.

It would be nice to see some kind of OpenGL plugin as good as my ElfData plugin. IE something that took a complex subject and made it fast and simple to use. Not seen it yet.

You don't need a plugin for that sort of thing ;)

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>