Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Ex

Pages: 1 ... 16 17 [18] 19 20 21
256
Programming / Re: Implementing stairs
« on: May 09, 2009, 12:12:59 AM »
My stairs are usually just standard objects with a destination level and location. The stairs are always generated in pairs though, so if I want to link level 5 and 10, I would generate a corresponding staircase in each, pointed to the level and location of the other.

257
New version of tinycurses. Lots and lots of changes, probably invalidated a 1/4 of the documentation. Anyway, added an mvprintw and mvaddch function. Lots and lots of things were fixed, most notably getstr now takes a length and is really quite nice about user input. Basic alpha blending functionality is there, but not as intended. Currently, anything placed on a layer other than 0 with a character other than ' ' (space) will display with an alpha value of 200. Of course, eventually you'll be able to specify the alpha for each tile, but this is just what I have right now. Everything else should work better than it used to, colors aren't changed on calls to printwext or clear.

Also, I majorly cleaned up the source code, it should be much better for including into things. I added the standard ifndef stuff, and put prototypes of all the functions at the top for ease of reference. Also, I renamed all global variables used in the library to start with TC_, that way they don't interfere with any variables of yours, but you can still access them.

UPDATE!:
Released another new version. This one is a small change, but it fixes a large bug. I wasn't properly writing everything to be included by more than one file, since most of my recent engines have been a single file. I've changed this, so TinyCurses should now compile without errors in projects with more than a single file. You'll need to include with your project and build TinyCurses.c when you build your application, though.

Get it here:
http://code.google.com/p/tinycurses/

Edit; Here's a screenshot:

258
Other Announcements / Re: Nifty article on Rogue
« on: May 06, 2009, 02:26:48 AM »
This is awesome! Too bad they don't link to Temple of the Roguelike OR Roguebasin :(

259
Other Announcements / Re: Roguelikes that rose above expectations
« on: May 04, 2009, 05:36:38 AM »
What are your games that rose above expectations? :)

Crawl. I'd heard a lot about it, but always assumed it wasn't as good as something like ZAngband. But then I played it, and now I play it all the time. I definitely should have not have assumed it wasn't good when I knew a bunch of people who play it. I'll probably play Crawl tonight even.

260
An interactive fiction roguelike is something I've wanted to make for a while, unfortunately I'm not very good at designing interactive fiction so I've never done it. It's a great idea though, IMO. Most MUDs are very CRPG like, having combat, levels, items etc. in an interactive fiction environment, so I think an interactive fiction roguelike is a very real possibility.

261
Definitely better than anything you've done.

The current version of Teemu has zero known bugs. The project has 60 source files.

No known bugs does has nothing to do with good source. Also, 60 files in and of itself to me is bad coding. Good coding is all a matter of personal preference, anyway. As long as it works, it works. I like my code, you like yours, and there's nothing wrong with either opinion :)

262
It's really rare occasion to see that bad source code.

It's fantastic source code, what are you talking about :> Definitely better than anything you've done.

It is interesting, I don't think I have before seen a library written all in a header file!  ;D  I was at first confused!

Here are some ideas, they are not big but might be "nice".
  • since functions are defined in the header.  guard the file by wrapping it in "#ifndef TINYCURSES \ #define TINYCURSES" ...rest of file... "#endif".  in case a user accidentally includes multiply, this will make it safe, and also gives them a define to test in the case that they are swapping several curseses in and out
  • try for booleans this: typedef enum{false, true} bool;  (it is basically the same but a little nicer)
  • good work on mouse, with automatic cell coordinates, but please look at the buttons somehow also ;)

Please keep up good work! :)


Definitely, I need to be using #ifndef and all that. I'm not sure why I hadn't included it sooner, just absent minded I guess. Button clicks on the mouse absolutely need a better system for detection, I need to work on that. Thanks for the encouragement! :D

263
I just released a new version of TinyCurses. It fixes a lot of rather large bugs, and implements some functionality that should have been there to begin with. Among other things:

- Printw now accepts everything that stdio's printf does.
- getstr now works correctly.
- All functions return what they're listed to in the documentation (Mostly 0).
- All functions should accept any input without crashing.
- Still no transparency support yet :( Sorry. It's finals.

Still a lot to do. Currently, any function that accepts a color (like printwext) changes the color of all text placed after it until the user of the library calls "color". I thought this was a good idea at first, but now I find it really annoying. In the next version, the color of text placed with addch or printw will only change if you call "color". Aside from that, I should really get transparency up and running, but I've been lazy. And I've been working on finals.

Get it here:
http://code.google.com/p/tinycurses/

264
Traditional Roguelikes (Turn Based) / Re: TinyCurses v0.9 released!
« on: April 20, 2009, 10:54:41 PM »
It uses SDL, so it should be able to compile for windows. But all compilers are different, and I haven't yet tested it under MSVC or Mingw. But I will do so soon. This is just the very first release after all :)

265
Traditional Roguelikes (Turn Based) / TinyCurses v0.9 released!
« on: April 18, 2009, 12:18:34 PM »
I've been working on a rather strange curses-like library called TinyCurses. Today, I released the first source code version. Since it's the first version, it isn't very tested and is likely to be a bit buggy. Also, alpha blending is not operational yet, but will be in a future version. You can find out more information about TinyCurses on it's website, here:
http://code.google.com/p/tinycurses/
TinyCurses is notable for it's support of Unicode and 32-Bit RGB color. It uses SDL and SDL_ttf.

Here's a screenshot:

266
Programming / Re: How to make sure every tile connects.
« on: April 11, 2009, 11:37:20 PM »
I must say I much prefer the simplicity of the traditional floodfill algorithm.  It is likely faster too (since you tend to use boolean checks rather than integer calculations).  The process:

Step 1: Choose an initial passable tile to work with - say the down stairs, or a random floor tile.
Step 2: Mark square as "connected" (a specific boolean flag for this purpose).
Step 3. For every square surrounding the last square, IF it's a passable tile AND IF it's not already marked as connected THEN repeat step 2.
(conditions are important to make sure the recursion eventually stops)

That's all there is to it - simple, elegant and quick.  If you want all of your dungeons to have no diagonal connections (so you can always use the arrow keys to move) then have step 3 only check the squares in the 4 cardinal directions instead of all 8 adjacent squares.

This doesn't ensure that connections are made between all areas of the dungeon, however :) The main point of my algorithm is to ensure that every tile that the player should be able to reach, he can reach through connecting unconnected parts of the dungeon.

Also, a flood fill is significantly slower than my algorithm since it requires more loops over the dungeon map.

267
Programming / How to make sure every tile connects.
« on: April 11, 2009, 04:49:58 AM »
I keep hearing about people who are having problems with their dungeon generator not connecting a bunch of rooms. So, here's an easy way to make sure that everything connects. First, you'll need an array of integers the size of the dungeon. Fill this array with the number -1 to start. Number every tile the player can walk on sequentially using the array, such that every tile that the player can walk on has a different number in the array.

Then loop over the array repeatedly. Any location in the array where one number is next to a different number, change the location's number to the different number. Further, change all places in the array that contain the location's old number to the new number. Don't change any numbers to -1 under any circumstances, ever.

Once that's done, find any two different numbers on the map, and connect those two locations. Then change every tile that contains the first number to the second number. Do this until there are no different numbers on the map. If you want a really good map, I suggest always picking the two closest different numbers, instead of picking two at random. Again, never pick any tile that has a -1.

Congratulations, every tile on your map is now guaranteed to connect. Here's a small example of how this goes:

Code: [Select]
Starting with:

#...#
#.###
#.#.#
###.#

First we number all the empty tiles, and place -1 anywhere we can't walk (On all the #s in this case). To make things look nice, I'm going to leave those as # instead of -1. Here's what we have after:

#123#
#4###
#5#6#
###7#

Now anywhere where a number is next to a different number the old number is changed to the new one. Here's an example in a number of steps:

#123#
#4###
#5#6#
###7#

#113#
#4###
#4#7#
###7#

#111#
#4###
#4#7#
###7#

#444#
#4###
#4#7#
###7#

Now we chose any two different numbers and connect them with some kind of hall, anything will work as long as those two spots are guaranteed to be connected.

#444#
#4#.#
#4#4#
###4#

And viola! All parts of the map are connected :)

268
Programming / Re: (un)acceptable memory usage
« on: April 10, 2009, 09:04:41 PM »
Yeah, I think the most important advise here is to NOT CREATE A NEW OBJECT INSTANCE FOR EACH CELL IN THE MAP.

Is this your advice for AgingMinotaur specifically, or a general rule everyone should follow?  In my own project, I was planning to make each tile on the map its own instance.

I've made every map tile an instance of a complex object in C++ without problems. But this is C++, and the memory usage in such an event is highly dependant on the complexity of the object used, and the size of maps. For instance, an 80x25 map is not going to take nearly as much memory as a 100x100 map. But in C++, generally the memory usage is extremely small even for maps of fairly complex objects. Just need to remember not to store graphical data in each tile :)

The best solution IMO would be to have a very, very small class that either points toward a common set of objects, or holds a copy of any one of those common objects. Thus, each map tile starts out pointing toward a set of more complex object, and if any map tiles need alteration the map tile creates a copy of the object it points to and points to the copy instead. The big thing here would be to remember to delete all copied objects on exit (Unless you have automatic garbage collection..), and also to save all copied objects.

269
Traditional Roguelikes (Turn Based) / Re: Prospector Alpha
« on: April 09, 2009, 10:21:08 AM »
Awesome work! This is a very creative sort of roguelike, and I love it. Good job!

270
Programming / Re: Kharne Alpha 1 Available
« on: April 09, 2009, 10:16:16 AM »
Very nice work! This game is coming along fantastically so far. I still remember when the old Kharne changed its name to Kharne, though I forget the old name... Anyway, great work, awesome to see Kharne so actively developed!

Pages: 1 ... 16 17 [18] 19 20 21