Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Outcast Orange]

I'm also learning opengl so it would be cool if we could share and comment each other's code.

I'd like to take you up on that offer.
I've always wanted to see the code of another beginner programmer.
The stuff I find online is so alien to me,
I always have to wade through it and can't understand any of it.
That's why it took all day to transform some
basic OpenGL structure into something I could use for my own purposes.

[Outcast Orange]

Is it drawing completely concealed blocks?

If you store a visibility byte, and AND it with the three visible sides to check if it can be seen, and don't even loop the completely invisible ones...

I had just started working on that.
Currently it only draws the front, sides, and top of each tile.
I know how to hide the completely hidden ones,
but that will add a second or two to the start-up time.
I guess it's worth the loss though...

[Outcast Orange]

I've got this thing running smoking fast!

I'll give you guys a try soon.
Check back within the half-hour.

[Outcast Orange]

Here we are:
http://www.mediafire.com/download.php?nhmjdlmnmdg
And the project folder:
http://www.mediafire.com/download.php?eidmm25fr2j

Spoiler (click to show/hide)

If it doesn't work, make sure you have this file in your system32 folder:
http://www.mediafire.com/download.php?yrkk2ahnozw

[qwertyuiopas]

Don't have rotation? Otherwise, looks great!

[Outcast Orange]

Thank you! I've been looking forward to feedback.
I'll get rotation in soon enough, but right now I'm experimenting with textures...

[qwertyuiopas]

Really, all you need is a glRotatef() and a glTranslatef(), in the correct order so that rotating uses the centre of the visible block as a pivot. And some simple math to select the closest +x,+y,-x, or -y to use as forward. Until you get into complex camera fly-throughs.

[Outcast Orange]

Thanks for the advice.
3D rotation works perfectly now.

It rotates around the center of the draw area,
so the cube of map displayed can be rolled around on the x and y axis.

I didn't think z-axis movement (roll) had much use in this context,
and I don't want to map over the entire keyboard just for camera control.

Eventually, you will have to select a piece of land to play on,
and some of the keys need saved for that.

I'm giving up on textures for now.
It seems like it would be confusing to implement, since they rely on external files.
Also, I'm not sure how to make my own textures.

Now, I'm going to write some sort of formula for "hellspikes", and add those in tomorrow.

[qwertyuiopas]

Textures *are* somewhat dificult. Loading them from files takes
a) An external library such as SDL that can load images
b) A custom format that can be easily translated by your program
c) A function or more than one that can be used to load an image

I use c), though not always for textures. Copying pixels as a font, or even copying pixels from a sprite sheet onto a diffrent image that is then loaded as a texture(Or updated) and used as background...

[Outcast Orange]

I'm going to be adding theses features by noon:

-"Lighting" from above (tiles on top will be light, sides slightly dark, bottoms dark)
-Optimize the input system to make coding the following easier
-Two keys to change zoom level (Maybe FG)
-Two keys to change draw distance (Maybe HJ)

EDIT: All features complete.

Next:
Suggestions?
I'm going to start prototyping the "hellspikes" now.

[Outcast Orange]

I've been working on a formula for hellspikes and I've come up with something solid.
The spikes will be very random, including:
-random base position
-random tip position (not dependent on base position) (might need altering)
-random growth variable (results may vary)

I'm going to add them in in a similar way to the cores.
I have thought of a problem though.

This huge wave of hellspikes to be added on startup has the possibility of severing multiple
plates from their cores.
I had decided that since only one plate (or group of plates) will ever fall at once,
the system could be simplified to prevent lag.
I don't want to surrender this option, so I will have to think of a way to protect plates.
I am considering having the spikes dead-end upon contact with plate material.

This will have a couple of side effects:

-hellspikes will not be an easy source of metals
Don't worry, I will add ore into the regular rock in local view.
The idea is that ores will be difficult to find/acquire, making things more interesting.

-they will push up against the bottom of plates,
so when there is eventually a collapse,
some of the plate will remain resting on the spike.
(I intend for these things to be ultra-strong, and nearly impossible to mine anyways)


Any suggestions?

[timmeh]

I need to get some chores done, but I'll test it as soon as I get the chance... talk about some amazing progress though, it hasn't even been a month and you've gone from generating a 3D sphere displayed in a text console to the floating islands with various features and in 3D!!!

[Outcast Orange]

Thank you, I feel the same way!

I'm having trouble with the hellspikes though...

I can only get them to generate at a 45 degree angle for some reason.
The procedure to generate each one is really long and complicated, (to save on processing time)
so it takes a while to spot my mistakes.
At least it's tapering to a point.

Also, the game doesn't crash anymore. (If there is a small chance that it will, I haven't encountered it yet)
I just reduced the privileges of the plates, and they stopped trying to ram
their growing bodies through the walls of the universe.

Basically, if it ever crashes with an returned error, the problem is a broken array.
Otherwise, the problem is a loop problem.
Currently I'm having loop problems that don't cause crashes.
Those are the hardest to diagnose. (In my experience)

[Outcast Orange]

I've noticed some other things that the hellspikes are doing wrong:

-they stop tapering at a 3x3 plain every time
-they always grow in the same direction

The second issue leads me to the solution.
I need to make the rules for growth more strict.

I'll tell you all how that works out.

[Killas[SiN]]

Wow, this is all pretty awesome!
I'm sorry if this suggestion is already present/implemented, but you should add moar physics.

You can nevar go wrong with physics!

Have you considered being able to 'move' the center of gravity around? I'm sorry if that's not exactly fluent, but I read one of your earlier posts and you said that you wanted some demented physics, and I reckon once the fluids, particles and gravity or what ever you call it are fully operational it would be awesome if where the mouse was it would become the center of gravity. Toggleable with a key stroke.

Also, here are some half baked ideas -

• Reverse Waterfalls - Instead of going down, the water flies up! (I guess you could make this by programming when particle touches 'block x' it moves to 'block y', regardless of physics.)
• Entropifers - A block where if an entity or particle touches it has one value randomly added, replaced or subracted. E.G - A rock touches the entropifer and has the [FLUID] handle added to it and the [SOLID] tag removed. It becomes fluidy!

I suppose that the 'Entropifer' idea could be used to 'seed' a world with unique life and rock, etc.
It could be when the world is generated, there are only a few elements present - mostly pretty basic. Every regular or so interval the program randomly selects one of the entities and applies a tag to it, removing any that conflict. The tags are selected from a predefined list.

E.G:
Entities X, Y & Z are present. Y has been selected for entropy. Y has the [liQUID] tag added and the conflicting [SOLID] tag removed.
-OR-
Entities X, Y & Z are present. Z has been selected for entropy. Z has the RGB values 200 150 126 present The R value has been increased by 80. However, it is capped at 255.

Sommat like that.

My 2 penneth.

Good luck!