UPDATES


http://binarydemons.com/~strike/files/lunar_physics.rar

fixed rar is now up. i hope all of you who were having issues with the second version have no problems with the new one.


other than that fix and the new error reporting system, not much (if anything) has changed from the second version.

if anybody runs the app and gets a reportlog.txt that is NOT empty, please send it to me at strike@fullsail.edu or post its contents here (unless the file is really huge)


i hope to implement object-to-object attachment (or 'welding') in the next version. this will enable all sorts of cool things in the engine: more complex objects, vehicles, articulated character skeletons (with potential for 2d ragdoll physics, perhaps even inverse kinematics) and limitless other possibilities.

yaaaaaaaaaaaaaay it works!


Its pretty nifty! I like the arrows to rotate the world.

Could you possibly make the option for a stationary camera, as opposed to one that always follows the yellow object?

I am most intrigued by this project.

Works.

FUN FOR THE WHOLE FAMILY!

<3 Aks.

I tried the second version you put it, but it didn't work for me. The new one works, though, and I think it's very cool.

I stress-tested it a little, and decided to see what would happen if I left-clicked and dragged the cursor away from the box as far as it would go. It got to around 'my:32,000' before the yellow block broke out of the box. Then it crashed.

New version works great for me as well, nice work! This is quite awesome.

hehe i appreciate the replies and testing

there have been several key issues i would not have noticed/fixed for some time without your help.

im still aware of the crash issue when the yellow object gets destroyed, i may as well fix it with next version.



ive got a billion and one things to work on to get things really off the ground, but i think developing some user interface controls is in order. i need to make an (integrated) tool to create a polygon (or polygons) for an object, and having some buttons and text fields and such would be mighty useful for that as well as other things. the collision poly for the AK47 was made by hand, typing in coordinates for the vertices; not the most optimal way to do it..

alongside that i will almost certainly implement support for multiple polygons for a single object, so that collision bounds can be more realistically defined.

after that, some more physics engine work such as the 'welding' i have mentioned several times will be important.

all the while i will work on getting more objects in - textured objects. it would be a pretty lousy game if all that could be created is solid-color convex polygons

Here's the biggest question: Are you going to provide massassi with this engine for free, and with good development support? I'd SERIOUSLY love to design a game for this. I can't code for **** though, so that's sort of out of the question anyway.

God I hate C++.

the engine already features LunarScript which, like COG, is based on a C-style grammar.


the differences are actually improvements over COG. note that all of these features are already implemented, in the lunar.exe that sits on your harddrive

- Function declarations with parameters (no more god-awful 'messages' hehe)
- Local variables
- Strings (including converting vectors and ints into strings and vice-versa)
- Dynamic Arrays
- Recursion
- Inter-script communication (loading other scripts, executing functions in other scripts, setting/getting the value of global variables in other scripts)
- Much better script timer support. Unlimited number of one-shot or recurring script timers that trigger any specified callback function. You can pass any number of parameters to the callback function as well.
- The "as" operator for explicitly type-casting between variable types
- Script commands with variable number of arguments
- Script instancing; each instance stores global variables and timers so multiple objects with the same script can have their own unique set of variables and timers
- Postfix increment operator for(x=0; x<100; x++)
- Reporting of errors during parsing and even during execution of the script (ie: launch.ls_errors.txt)
- Unlimited number of named variables that can be assigned on an object. Not exactly a scripting language specific thing, but think of SetThingUserData on crack

the scripting system is tried and true; we used it to handle all of our character's attacks and special moves for final project game at full sail, as well as logic for the fight matches and even displaying the splash screens when launching the program.

since its been a while since ive posted any updates:
project is most certainly not dead, but my computer most certainly is.


cpu fan finally crapped out, and when i replaced that my monitor simply doesn't turn on (even if it is not connected to a computer, the little power LED comes on; up until now, at least).

ive got all my files on my laptop but its a little less likely im going to work on the project until i get the desktop back up; laptop keyboards not fun to bust out hundreds of lines of code on


im solidifying the list of types of UI controls that are needed, trying to preplan what elements can be reusable to set up a decent hierarchy. how i hate rewriting the same garbage for similar objects

poke: What about my question?

i haven't had the specific intention of releasing this to massassi as like a base SDK for making 2d games, but that doesnt mean it cant/wont happen.

make one for linux or else..

sorry, probably not going to happen

just implemented some more operators for scripting language. havent looked at some of that code for months lol

all modifying assignment operators that can be found in C, with the exception of bitshifts, are now supported for all variable types

+=
-=
*=
/=
%=
|=
&=
^=


well, not quite *ALL* variable types; depending on the operator. it would be kind of strange to bitwise XOR a string with another string wouldnt it?






also, i got some framework laid out for user interface elements. these elements can be created and manipulated in script, and specific types of elements can trigger script callbacks. a good example of this would be a button that triggers a script function when it is clicked.

(potential) element types
-----------------------------------
-static text
-edit box
-list box
-button
-image/colored rectangle (possibly drag-and-droppable version as well)
-"window" frame
-scroll bars (to be used primarily in list box)
-checkbox
-radio button

all elements have the capability of having children attached to them, similar to windows programming. however, the most likely use of this will be just attaching controls to a "window" frame (although other controls, such as the list box, may use multiple attachments internally).

the whole UI thing is already proving to be a big challenge; not because it is hard to create a list box control, for example, but because i would *like* to make them look good as possible. flexibility is important to me; i would like people to be able to 'skin' the entire UI system whilst preserving the same functionality, but im not sure i have enough UI programming experience to really set that up effectively. i suppose the worst-case scenario would mean that you could do nothing beyond changing colors. there's a lot more to do than spend loads of time on UI coding, anyway

Especially with a physics engine. I'd LOVE to be able to make some kind of castlevania like game.

No *nix version? Bleh. Why don't you use something like Cmake to facilitate cross-platform builds?

will directx run on linux? i always figured that directx was a windows only thing, though i suppose there are probably ways to get directx to run even on my microwave (which would be pretty cool).

honestly though, ive never written anything for linux; i havent even USED linux.


if it proves to be easy enough, then i'll do it.

if it is going to require a good deal of work then i wouldn't bet on it. in the end, this is still primarily a project for fluffing up my portfolio

AND for letting JediKirby use it for his own purposes.

>.> <.<

Right?

Well, considering there is no DirectX in Linux, the port would be nontrivial. You would have to reimplement the engine using OpenGL and SDL. Of course, OpenGL and SDL are cross-platform too, so you would only need to do it once, but that is besides the point.

You should give Linux a try. I find programming to be a lot nicer in a Unix environment, though that is personal preference.

really, it wouldn't even be that much work to get rid of the directx dependencies - only a small handfull of files use anything from DX; unless you count the flagrant use of D3DCOLOR/D3DCOLOR_ARGB all over the place - but that is easily macro'd or find&replace'd.


i wont give a blatant and final "no" to porting it, but let us say it is very low on the priorities list.




as far as updates are concerned, there's some more work on the UI stuff.. all of the GUI stuff currently in the app is now created thru script. i would take a screenshot except it looks identical to what you've already seen (which is a good thing).

minor update to utility library: the case-insensitive string hashing function was apparently generating the same hashcode for "vec" and "vecX". made hashcode gen a little more complex, which fixed the problem. if anybody has a super good hash func, please share it

Updates

little sneak preview at some of the UI stuff im working on: the window frame!

-resizing the window wont stretch border images
-titlebar is optional
-border size is adjustable
-title bar height is adjustable
-colors can be modulated
-can be reskinned via "UI Template" config file


(note that the slightly darker transparent background in the frame is temporary; i just didnt want to leave a big gaping hole there hehe)





script code to create window frame shown in screenshot:



also reworked error reporting for script system to use the same error reporting route that the rest of the engine uses. although this means that script errors will be reported in the same cryptic context as everything else, it means that it will be easy to redirect the output of the messages from a lame reportlog.txt to a cool GUI window.

even though i wrote the damn script error reports, 75% of the time they dont help me find the specific issue when a script isnt parsed correctly. over time this system will improve and error messages will generalize to report more user-friendly reasons why something could not be parsed. reporting the line number or even displaying the whole line where the error occurred is also a very reasonable possibility.

heck, it may even be possible to integrate a script editor directly into the engine, complete with command and constant value listing and highlighting specific lines of code that contain errors. if the UI elements turn out as powerful and easy to use as i am hoping for, it is a very likely possibility. this would be a great utility to go alongside the level editor, which is most certainly going to be integrated.

That's pretty cool. The window looks like it'd make a good console.

my report log was empty :thumbsup:

hmm, maybe I'm the only one having this problem, but when I run that, everything is really... jittery. Any time I move the cursor, it jacknifes back and forth, same with rotating the screen or zooming in and out. Makes it almost impossible to do anything. The first version you put out did not have this problem for me, but version 2 and 3 both do. I'm running Win XP Pro, with Dual Core AMD Opteron proc, and GeForce 7600 GS (SLI).

Error log is empty.

you say the latest version does *not* have the jittery issue? if so, im glad its fixed, but im scared to not know what was causing it.

somebody else said the mouse was jittery in one of the older versions too, but he was also having the whacked out graphics issue that was with ATI cards.

if you were not having the jittery issue on the very first version, then it is probably due to the graphics garbage i was toying with in the 2nd (that broke for a lot of people). i am still not sure exactly how that could be causing jitteriness, or perhaps i'd have to see it to make a better assessment. 'jittery' seems to be the right word though, since that's how the other guy described it as well.


most of the probs that arise particularly this early in the build are due to hardware or other low level code that hasn't really been fine tuned or bug-fixed, so the report logs are typically going to be empty. however, just about every new class i write implements the Reporter base object, so when things go wrong im starting to see messages; they have been starting to prove their worth while developing.



the window frames are now resizable and draggable using the mouse. i hacked together a little radar window that ill probably use to sort of showcase the new UI stuff, so a new build is probably coming soon.




i turned off the 'mouse velocity' while working on resizable window stuff (made it easier to grab the edges), and when i turned it back on i realized how much i hated it. the smooth movement aspect is nice, but it doesnt feel very responsive, so im tempted to rework how it is handled.

(by not very responsive i mean you can move your mouse very fast but the mouse cursor does not accelerate quickly from it)

UI UPDATES


still all reskinnable

Oh yum!

It's showing an inaccurate number of dots ... ?

could be


first of all, it only shows dots for the little red boxes

second of all, the 'radar' is extremely hacked together, just so the window isnt empty

when there's more UI goodies, or at least code for a decent background, the 'radar' will go poof =)

MORE UPDATES

-all edges and corners of window frame are grabbable to resize the window
-added alignment property to text skin (left, centered, or right-aligned)
-finalized text caption ability for buttons
-added 'contract' button to window frame (yellow round button)
-basic scrolling and scrollbar functionality


as far as the window frame is concerned: the titlebar, close button, contract button, and scroll bar(s) can each be added/removed by changing the 'frame flags' of the window.

scrollbars are the latest addition (started today) and are about 35% done. the little square buttons you see on the bottom and right sides of the windows are the scrollbar buttons. clicking and holding on the buttons will scroll the contents of the window, but there still needs to be the actual scrollbar in between the buttons, and the little draggable piece that lets u quickly scroll to a specific position.



text boxes are next on the plate for when scrollbars are completed. i still need to figure out a good window background theme; im starting to think perhaps solid color is the best i can hope for

UPDATES

scrollbars are done, finally (yay!)
like everything else so far, scrollbars are skinnable

now to move on to text boxes >=)


i also disabled v-sync, so framerate has gone through the roof (not in this screenshot though)

UPDATES

textboxes are done, or at least as done as they will be for now. they behave like one would expect - u can click to set the cursor position, use cursor keys to move cursor position, use delete/backspace as you normally would to remove characters from cursor position, and home/end keys also seek to the start or end of a line. textboxes can optionally accept multiple lines of text.

only thing i didnt get in there is being able to select portions of text, which also means no copy/paste support. this MAY change in the future, but i decided it was time to move on; you know, to the GAME.


so it is time to start putting these GUI elements to use for the very reasons they were created. the integrated collision polygon editor is underway as of this morning, i would appromixate about 35%-ish completed.

currently you can insert polygons, drag whole polygons around, drag individual vertices around, and click on edges to insert a vertex where you clicked. polygons can overlap with no ill consequences. the workspace can be dragged around with right-mouse button and zoomed by dragging with CTRL+right mouse button. considering the fact that all polygons must be convex for the collision detection routines, the fill color will change to red if a polygon is detected to be concave.

considering it is a 2d engine, some of you may be confused why it is called a 'model editor'. i couldn't really think of any other words, and i feel 'model' is as good a term as any for the marriage between a set of 2d collision polygons and the 2d image they are intended for (similar to a texture and the 3d mesh it is intended for). generalizing the combination as one unit will make it very easy to swap out 'models' for objects, and very hard to get the wrong collision poly set mapped to the wrong image.

the neat thing about coding the entire model editor as a GUI element means its very easy to pop up as many editors as you want; perhaps using one as a reference, or working on multiple 'models' at one time


note: yes, i am aware the image is squashed
framerate would be several hundred if this wasnt in debug mode

UPDATES

have been working on lots more stuff for lunar, still almost exclusively GUI stuff.
the last core element that i want to be sure to add is the list box; which will make adding console windows extremely easy. given the preexisting functionality of the scrolling frames and text elements, the list box will be very easy to implement; probably a 1-day job.

New stuff highlights
--------------------------------------------------------
- Tooltips that pop up with mouse hover-over
- Alpha/offset transitions for fading in/out elements or sliding on/off screen
- A few new flags for base element class (EXTERNALCHILDREN, INTEGRAL, FADE)
- Radio buttons
- Check boxes
- Dynamic local var system added to base element class; giving ALL elements the ability to store any number of string-assigned values of any type compatible with script system
- GUI file resource system; this will be used for loading/saving resource files, and the framework can also be used for transferring objects (in memory or on file) between editors/tool windows. this is at least 60% completed.

of course, all of these features are fully available thru script.
i am also considering adding a 'syscall/constants' library to the engine that will list all globally registered script commands and constant values (flags, for example) as well as a description for each one. this would tie in nicely with an integrated script editor. the text boxes are just highlight and copy/paste support away from being everything Notepad can offer and more; which means an integrated script editor is not a very far-fetched idea.

also been thinking of some ways to support articulated, animated characters with the least amount of effort and complexity (both for coding it and useability of it). i think i've got a good solution in mind, and will work feverishly on getting it in once the filesystem GUI and listboxes are complete.