- Age / Gender:
- 20, Male
- Location:
- Earth, Milky Way
- Joined:
- 2/16/06
- All Stats >
I'm just some guy who lives on a planet somewhere near someone else. Maybe that someone else is you. I'm not sure. Might have Flash stuff up, might not.
User Statshot
- Community Stats
-
Level 9 Blank Slate
-
Normal Whistle
-
Ranked as Scout
Latest News
Been a while.
I recently revisited what until recently was known as ASymmetric, and have decided to rename it Paradox, after Platinum Paradox Productions, a company that I have had in the back of my mind for some time. As a result, I have rewritten the pseudo-OS yet again, and have worked to incorporate several new ideas. Among them, I used to have a set of wrapper classes for certain essential AS3 classes. I have discarded this idea in favor of a "package" instruction that takes a user-defined object (though likely one defined in the kernel) and converts it to an opaque AS3 object. I am still considering whether this operation should be an instruction unto itself, or a gfunction.
On that note, I have largely scrapped the all-caps syntax of older versions, and intend to implement a case-insensitive lexer.
Another big instruction is "class". This creates a new object template in memory, and assigns the subsequent "class_method," "class_member," "instance_method," and "instance_member" calls to that class. An "end_class" instruction flushes the new class to the local datatype segment. "Get_member" and "set_member" work as they used to for these, though to access a class member, the class's name should be passed. Instances of the class have the same access to class members, so that will still work, but no instance is needed to access class members.
To use class and instance methods, the "call_cmethod" (class) and "call_imethod" (instance) instructions were devised. Here, the infixed letter determines whether to look for the first param in datatype memory, or the stack. I presume a "gcall_cmethod" and "gcall_imethod" are forthcoming, for accessing methods of global objects and classes.
I also decided to shrink the instruction signature from four parameters to two by moving the process's compiled token and depth arrays into read-only segments of its memory.
Another idea I had just earlier today was to institute a series of checks done at compile-time, ensuring that instructions only make valid assignments, such as ensuring a "set" instruction assigns a string to a string, and not, say, a boolean to a string.
I feel it may be somewhat tedious rewriting the lexer and linker yet again, but to ensure they work the way I want them to, I will soldier on.
One other instruction I also look forward to implementing is the "hook" instruction. This tells the program where to jump to when an event occurs. Most of these will have to be assigned in the kernel.
I also still have to give some thought to whether there should be a way to allow a variable to be looked up at specific scopes. This is particularly for allowing explicit access to global scope, but other situations may certainly crop up. I have no dearth of symbols I could use, and have been considering using square braces for a global lookup.
Lastly, I've been considering an instruction that allows the programmer to access a member of the executing process, though due to the internal structure of the system, it would be limited to public members. This instruction would only be accessible from the kernel, and would end up calling "executor[token1](otherTokens)" in its implementation. Mostly, this would be used for drawing commands.
The latest script I have been using to demo the current (intended) syntax is this:
class "MyClass"s
class_member "string"s "clsString"s
class_method "setStringc"s
.set {clsString} "This is the class string."s
.return
instance_method "setStringi"s
.set {clsString} "This is an instance string."s
.return
end_class
call_cmethod "MyClass"s "setStringc"s
new "string"s "myStr"s
get_member "MyClass"s "clsString"s {myStr}
gcall "Output"s {myStr}
comment "gcall syntax likely to change"s
new "MyClass"s "myObj"s
call_imethod {myObj} "setStringi"s
get_member {myObj} "clsString"s {myStr}
gcall "Output"s {myStr}
comment "Program over."s
In other news, I started work on a C++ framework by the same name as the above, differentiated by having the destination language prefixed to the name. So the framework in AS3 is "AS3 Paradox", and the one for C++ is "C++ Paradox." I note that the two are virtually unrelated other than the name and programmer. While AS3 Paradox is a frame management framework, C++ Paradox is a system abstraction framework, primarily, at this point, for Windows and Linux. I still have no easy way to test on Mac OSX systems, due to the very prohibitive cost to entry (namely, the cost of a testing platform). I do intend to support that platform eventually, but it is not a priority for me.
C++ Paradox grew out of a distaste for another 3D game engine I researched, Irrlicht. My problems with this primarily focus around its lack of use of DirectX 11 (and 10) and OpenGL 4.0 and 4.1. Despite this distaste, of course, my video card supports OpenGL 3.3 at maximum, so any testing I could do with versions beyond this will have to wait. There is also a twinge of NIH (Not Invented Here) syndrome. Other systems besides rendering I intend to provide include networking, a more intuitive windowing system, and script management system. This last one probably won't have any built in implementation for any specific language, though I imagine I will use it for Python and compiled scripts (scripts written using the scripting device but compiled into the executable rather than loaded from a script file) most often.
I recently reviewed the code, and decided to begin again, changing the backend on most of the devices so that, for example, the console had its input and output functions built in, rather than realized as separate components. Also, the main objects are being programmed as static libraries, which will be linked together into the Paradox dynamic link library (Windows) or shared object (Linux).
During v1, I told myself to make the code for Windows first, but this philosophy has been scrapped. I intend to make it work on both Windows and Linux concurrently. What I am looking at is whether to use the X11 interface on Linux, or perhaps a toolkit, such as GTK or Qt. The problems arise because, due to my use of the Express edition of Visual Studio, I only have access to Windows' Win32 C API. I am unsure whether, due to this limitation, I should use Linux's C windowing API. While it makes a certain sense, I have yet to see certain functions that would make the concurrent production easy. For example, Windows provides an easy way to create a button (insofar as doing anything with the Win32 API is easy). All the tutorials I've seen for doing the same with X11 involve drawing the button programmatically. I have no problem with this, as I made a programmatically-created button class for Paradox. However, I would like to see if a simpler solution is available.
Also, I decided to get my fix of World of Warcrack yet again. My main, Locholovis, is, at time of writing, level 73. It is more than likely that I will never play end-game content when it is actually at the end of the game. As it stands, I will likely have to fight just to do Icecrown Citadel (though I really do want to do that at least once). My tank warrior, Rallam, recently ventured into Outland to get Fel Iron, so that he could make a Fel Iron Rod for Locholovis. His Enchanting moves faster than Rallam's Blacksmithing can keep up. It's pretty annoying.
I had some tentative plans to wait until my birthday to update this, due to the line of "Still Alive" that comes next. However, I figured no one really cared, since no one reads this blog. I quietly append the qualifier "yet" to my previous sentence.
YOU JUST KEEP ON TRYING 'TIL YOU RUN OUT OF CAKE.
Recent Game Medals
Total Medals Earned: 376 (From 12 different games.)
Favorite Audio
| Operation: Evolution | Techno Song | |
| A Piano's Testimony | Miscellaneous Song | |
| Princess Mononoke rock/orches. | Classical Song | |
| Black Hole Earth Consumption | Heavy Metal Song |