Here are some of the random locales you will be visiting:
(these are actual ingame shots of the procedural engine, not a mockup like the first one was  )

Just a keepalive. I've been working all weekend on this, so some tasty screenshots and actual game details soon.

[Biocosm for Windows]

Biocosm for Windows

Biocosm for OSX

DISCLAIMER: It's super buggy and there are some severe memory leaks. Also there are no loading screens, so be patient. I'll try to patch this stuff up tonight.

Unfortunately I had no time to finish what I wanted to do, so this is more like a demo. Hope it's still fun though!

Sorry there are no ingame instructions, so here they are.

Use left and right arrows to navigate your specimen collection unit.
Hold spacebar to close the specimen holding pincer.
Collect specimen and bring them to the extraction beam.


Code by yours truly
Music by my friend Mike

It's mostly for fun and to test out skeletal animation in my engine at some point.

the problem with doing vectors with actual vertices is that a) you end up with an ungodly amount of them if you have alot of complex smooth curves and that can add up pretty fast even for modern cards and b) you need multisampling extensions for antialiasing (you can do antialiased LINES on any card, but for anti-aliased polygons, which you need for doing shapes without a stroke you're gonna need hardware AA). Not rendering to texture so that you have the ability to manipulate the lines is  a bit silly because to do it fast, you're going to have to have the vertices in a vertex buffer anyway, so you will only be able to change it with a vertex shader and on cards that support vertex shaders you can render to the texture with either a fragment shader or framebuffer anyway.

Edit: (that is concerning rendering complex vector objects from svg files or something of course)

started on this awhile ago but now it sits abandoned until i sift through my workshit.

I made these a couple of years ago.

Click to regenerate.

http://www.ivansafrin.com/processing/atoms/atom1.html
http://www.ivansafrin.com/processing/atoms/atom2.html
http://www.ivansafrin.com/processing/atoms/atom3.html

Also i was doing a collaboration with a photographer friend of mine, me doing some procedural generation stuff based on his photo which resulted in this.

I'm in like bathtub gin

http://www.youtube.com/watch?v=Z0kVPVnZKdQ

http://www.ivansafrin.com/rgs/nanodoc/

First output from my custom doc tool. Need to finish documenting every function though still.

Yep. I just finished writing my experimental documentation tool, so i should finish commenting stuff later today and then i'll post it up along with a simple tutorial.

Hmmm. I've never distributed a framework before, but i've used install_name_tool on stuff with incorrect pathnames before. The old SDL framework had this problem i think. If you want to help me fix it, that would be rad

Hello,

This is a project I've been working on for the past few months. It's a C API for quick and easy creation of simple 2d games with a heavy focus on tilemap-based platformers. My mentality with making it was a sort of Game Maker for C It includes an editor where you can edit alot of the assets and then put them together with just a few lines of code.

I wrote Tiny Platypus Pimps with it and the source for that is on the project page as well. Im going to use this myself for a few upcoming games and this will be the engine for U-Head as well.

It's a work in progress still, so this is an alpha release as there are some bugs still (mostly in the editor).

I made an Xcode framework for OSX and vc9 and mingw sdks for windows. Let me know if you experience any problems with them if you check it out. You're going to need the SDL SDK as well.

I am generating some documentation for it right now and writing up a little tutorial on how to use it.

You can get it all at:

http://librgs.googlecode.com/

Here's a screenshot of the editor:

http://www.ivansafrin.com/crap3/rgsedit_final.png

Here's a brief feature list:

General Features:

   * C99 (should be usable from C++, but really designed for C)
   * Crossplatform (OSX,Windows and Linux) (DS support coming later)
   * API-independent, tho currently reliant on SDL
   * Small and fast

Editor Features:
   
   * Sprite animation/bounding box editing.
   * Visual tilemap editing (place entities, define collision and attribute tiles in layers).
   * Single tile or brush tile editing.
   * Arbitrary game settings: attributes, entity and brush presets can be saved to files.
   * Bitmap to tilemap import: converts a bitmap to unique tiles of arbitrary size, then creates a map file from it.

Graphics Features:

   * All surfaces are paletted 8-bit
   * Load palettes from .pal files (editable in Photoshop)
   * Loads sprites from custom sprite file format editable in the editor
   * Loads static graphics from custom image format (convertable in the editor)
   * Optional NTSC emulator filter. (via Blargg's NTSC lib)
   * Arbitrary screen size (initialized with two resolutions, one actual and one screen).
   * Automatic rendering queue based on screen layers
   * Easy text rendering with two built-in bitmap fonts

Sound Features:

   * Plays music from NSF (Nintendo Sound Format) files. (via Festalon)
   * Plays sounds from the native SFXR format (sfs) (via Dr. Petter's SFXR)

Tilemap Features:
   
   * Automatic entity to tilemap and entity to entity collision detection and gravity
   * Atomatic entity loading (in the code predefine the sprites and update/init functions for each entity type, then just load the .map file)
   * Scrolling support + follow entity.
   * Arbitrary tile size
   * Tile data and tile graphics loaded from separate files.

Basic UI Features:

   * Buttons
   * Scrollbars
   * Text Input
   * Select lists
   

RGS does NOT compile in linux right now. I'm going to check out why this weekend.

Aside from bugfixes, i'm planning on making Python bindings for it and maybe a little UI for the python so you can do everything in the editor.

Cheers!

i love you?

Yay Russ! Those are all awesome. I think the music challenge should be a regular thing here.

Also, if you want to get into the details of things, random numbers on computers aren't random at all either. It's just a algorithm that comes up with a sequence of numbers based on a specific seed. That's why when you use the rand() function in C, the random numbers are the same every time you run the program and you have to seed it with something like current time.

Yes, procedural has nothing whatsoever to do with randomness. It means simply that things are generated based on a certain algorithm. The input to that algorithm however, can be random so as not to have the same result every time. But that also doesnt have to be. .kkrieger, the 96K shooter, for example, generates all of its content procedurally, but it's the same every time because it's based on static settings.

welcome to tigsource! oh wait..

Photographs and Demakes (we have to do the demakes.. you proooooooomised)

10 in no particular order

Xcom
Fallout 2
Morrowind
Rez
Monkey Island
Half Life
Half Life 2
Soul Reaver
A Link To The Past
Portal