Messages

No antivirus, and I ran it as administrator. I ended up installing v14 from a mirror I found here, and that seems to be working ok. Thanks anyway

Am I missing much by using 14 instead of 15 or 16?
I wasn't able to find specific release notes.

Hi all It's been a couple years since I used GLBasic and I wanted to get back into it.

I downloaded the latest from the site (found out about the steam version after) and let it update.

I then put in my code and it said "your license code is correct. thank you for your support." and then remained the trial version. I tried restarting and running as admin and same thing. I then found out that no matter what I put as the license code (for example a blank space or the letter b) I get the same message. Any ideas?

By remain the trial I only see win32 and win32dll as multiplatform options and I still see the registration window.

Thanks

Yes, yes, and yes All things I have planned and want to implement (and things which I wasn't able to make look right in my 2d versions previously). I think the jump to 3d for display will make some of those much easier to work with. Jumps/ramps are an interesting addition too, and shouldn't be too hard since I'm dealing with "y-axis physics" already. My next hurdle is to make bridge sections, which I will then improve into roads being able to cross over each other.

Thanks!

Yup, no invisible walls. I'll have some rudimentary "sliding down slope" physics for handling varying terrain. Of course there will be trees and fences and other objects in the way that might prevent the player from changing branches, but otherwise it should be freeform.

In the method I settled on, all branches follow the curves of the "master" road. The idea would be more for forks in the road as 'shortcuts' or bridges or pit stops than for a T intersection, for example. This keeps multiplayer (which is a goal) simpler in terms of tracking all cars and objects with x/y/z in a linear fashion. I can make use of the terrain in between roads (and spread the roads very far apart) to make it "feel" like it's independent, like in road rash or similar games where there's branch options which then meet back up later on (with some mountain-y terrain in between). I also want to use the branches as a more conscious "making choices" mechanism, where a powerup might be on one branch and danger on another.

Hi again Just an update on how things have progressed:

I redid everything in a new project after doing prototyping, and then of course proceeded to mess up the cleanliness of it when testing new things My main concern was handling multiple roads. I've seen lots of pseudo3d roads online, but not many implementations of road splits. I tried several options, but settled on the one I will show below. While it has some limitations, I think clever map design will hide most of them

Some videos:
first: http://youtu.be/lRQxHKE_NT4
This shows off height changes between road branches, as well as texture changes on the sides of the map (road texture could change in a similar manner). Ignore the jumpiness of the vertical changes, I didn't put any smoothing on it yet.
Second: http://youtu.be/7qFWum5kwPw
This shows another branch at the same time (you can have up to 5 roads on the screen at once), veering off to the left through a curve and then when it straightens out again. In a future update I'll combine both of these functions to create "overpasses" to take cars from one side of the map to the other above the 'ground' roads.

Thanks

Yeah the demo was tied to framerate, no smoothing, so that could have been some of what you saw. It was also somewhat fixed in view, which will definitely be improved upon. Lots of areas for improvement.

Mountains or hills could be done by replacing the flat striped area with some pyramid shapes or a few more polygons. I want to add things like a bridge over water, guard rail, and some mountains and hills along with objects on the sides to give it some flavor, as well as road splits and merges for branching choices.

The ultimate goal would be to make something that puts these games in a blender: road rash, outrun, san fransisco rush 2049, f-zero, and similar

Thanks, that is how I ended up doing it, though at first I had autonormals and that was probably causing some slowness as well.

erico: I always like good music to go with programming

There's definitely some optimizations I can do, such as increase the size of segments in the distance, but for now it works well enough.

Had to wait overnight for the vids to upload and process, but here they are:
10 lines per segment: http://youtu.be/k7P5SibwVHs
20 lines per segment: http://youtu.be/TgbFcqDf8zk
30 lines per segment: http://youtu.be/k_Jnl8bUGzQ
some notes:
- the stuttering I think is from using FRAPS (probably dumping info to disk). When it's not on, the demo doesn't do that.
- in the 10 lines per segment video, I move the camera around at the end to show the true 3d nature of the pseudo-3d track, and the advantage of going this way (instant change in perspective). I forgot to turn the camera, though that works as well and is useful at certain angles.
- I didn't take the time to change the texture coords for different segment sizes, so that's why the road looks squished or stretched depending on length.
- there's more warping/distortion than there should be on the segment closest to the camera. I struggled with that one a bit, and have some fixing to do on it still. I was hitting some odd drawing results for some reason when I crossed z=0 into the negatives. I didn't want to get bogged down on that issue so I made a workaround for now.
- the cars float a little, and don't adjust their pitch for the road. I wasn't able to get the scaling as right on as I did when I was using sprites, something I'll fiddle with later on.

I might do that later on, I had some issues with my android emulator and don't want to get too sidetracked right now

I'd be happy to post a vid of it in action. I'll do a couple runs at different segment sizes so you can see how it affects smoothness.

For my testing at least, 1 object with 1000 verts is better than 100 objects with 10 verts. Your mileage may vary

I let the size of the road segments be user-selectable at runtime for the test. In the above pic, each segment was 20 'lines' worth, and it's showing 1000 lines, so 4 verts * 50 strips * 5 columns (2 for the sides, 2 for the grass, one for the road) = 1000 total.
Good performance on my super-low-end laptop. Performance definitely favors the static meshes, as each of the cars shown have more than that and I have 500 of them spread out on the road (probably 50 or so in any given shot). Creating one giant mesh of all the strips together might perform even better, but I wanted to give them separate textures and it seemed the easiest way without messing with a supertexture and worrying about the coordinates on the vertices.

On my higher end desktop, I can go to 10 lines per segment and still see better performance than my laptop, however lower numbers after that start suffering. I'd assume a cpu bottleneck rather than the gpu, but I'd have to do more tests. Full screen vs windowed didn't seem to have an affect on framerate.

At first I had a separate object for each road segment, and edited them each time of the game loop. That worked decently for a while, but as I added more segments for sides of the road, I started hitting odd performance issues. It seemed some internal garbage collection or something was causing issues. I also hit some non-debug-catching access violations if I added too many objects. I then decided to try pre-rendering segments of -30 to 30, but found it too limiting for the smoothness that is a hallmark of the pseudo3d road. Finally, I went back to the original method, but created one object for the whole road strip. This had good performance and scaled well to allow me to make the grass on the sides as well. Attached is a pic of the result. Thanks for the help

Fair enough. I did have some success with using matrix multiplications to skew segments, but the math to get a whole level working is more than my brain can handle right now I'll give object creation a try next to see performance.

I was thinking, maybe in this case where I'm basically skewing in one or two directions (left/right for curves, and up/down for hills) i might be able to get away with using x_multmatrix per segment to accomplish the skewing. I'll try a few things.

Thanks for the info. Not to sound completely ignorant, but is there a reason it can't be done (I don't know much about the internals of OpenGL so maybe it has to do with where objects get stored or put in the pipeline)?

I was looking to fiddle around with a polygonal pseudo-3d road like this: http://www.extentofthejam.com/pseudo/#proj3d as I've already created a few non-polygon rasterized versions.

Is there a way to modify the vertices of an object after it is created? Like an X_SETFACE command or something. I have a series of quads that I want to stretch and twist each frame, and the only way that I can see to do it is to create new objects each frame. If I'm missing something obvious please let me know

Yeah, I've done a phonegap/cordova project before and all the resolution options can be a pain to say the least. Thanks everyone for the help. I'll be checking out links and more searching on the forum for scaling ideas. I did try bluestacks again and figured out how to use it, must've just been too tired yesterday. Now I've at least got a system to work with. Thanks!