Pages: [1] 2
  Print  
Author Topic: Possible New Renderer  (Read 3992 times)
jonoerik
Champion
***
Posts: 196



View Profile
« on: June 26, 2010, 01:03:00 AM »

Recent development in libtcod has seen the inclusion of 2 new rendering options (GLSL and openGL), along with a number of benefits that these offer (1000+ fps).  But I was thinking, why not offer an even larger range of renderers.  The one I'm thinking of is ncurses.  Some features wouldn't be present when using it; the font choices would be somewhat simplified, the true colours would have to be rounded down to 16 and the mouse support would be less accurate.
But look at the gains!  Libtcod games would be even more portable: playable on a linux system without a window manager.  And gamers would finally be able to feel that authentic retro style of the first roguelikes.  Plus, libtcod would be offering a decent interface to ncurses; instead of the exceedingly cryptic one currently available (which jice has already mentioned disliking).

Note: The above post is not to be taken seriously under any circumstances!  Could be an interesting addition though...
« Last Edit: June 26, 2010, 01:05:42 PM by jonoerik » Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #1 on: June 26, 2010, 07:14:51 PM »

So, is this a serious feature request or not? Smiley That sort of renderer would basically ignore the font, ignore the custom mappings, ignore the mouse, and even ignore most colors as they'd all be converted to the closest one of the tiny color palette... If you wanna play games you can't have a "linux system without a window manager" Tongue I don't see the upside unless the goal is to serve games over telnet or ssh; that would be pretty cool actually... Someone else would have to code it though, I can't imagine Jice being completely psyched over this hehe Grin
Logged
jonoerik
Champion
***
Posts: 196



View Profile
« Reply #2 on: June 26, 2010, 11:28:53 PM »

Not exactly a serious request, but more of something to think over.  On the other hand, some quite decent cross platform applications could be written, where you get the nice graphical (but still ascii) interface under a window manager, but still works in command line.  I can't see anyone coding it though, nor can I see anyone seriously using it.  You'd also get issues with small screen sizes (in terms of tiles).
Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #3 on: June 27, 2010, 01:27:40 AM »

Well, it would be nice if just for the "play over the net" thing, it's the main argument I hear when people discuss libtcod vs curses. I'm sure it would bring some people over from that side of the fence Smiley But again, someone would need to volunteer to code this and Jice always has the last word Smiley
Logged
linux_junkie
Master
****
Posts: 222


View Profile
« Reply #4 on: June 27, 2010, 03:12:23 AM »

Well, it would be nice if just for the "play over the net" thing, it's the main argument I hear when people discuss libtcod vs curses. I'm sure it would bring some people over from that side of the fence Smiley But again, someone would need to volunteer to code this and Jice always has the last word Smiley

Wouldn't the easier solution be to just add networking support to the library?  I thought of doing that for my lua wrapper (since I've already added sound), but haven't gotten around to it yet, because I was unsure of the demand for it.
Logged
mingos
Global Moderator
Master
*****
Posts: 583



View Profile WWW
« Reply #5 on: June 28, 2010, 08:48:04 PM »

Jice already refused to "cursify" libtcod on various occasions. The whole point behind libtcod is to offer an alternative from curses. If you wish to use libtcod's additional features, such as pathfinding, you can use the fragments of libtcod's code in your own program (and/or library) using curses.
Logged

If debugging is the process of removing bugs, then programming must be the process of putting them in.
- Edsger Dijkstra
TSMI
Champion
***
Posts: 160


View Profile
« Reply #6 on: June 28, 2010, 10:26:38 PM »

Java Terminal would be better than ncurses, IMO.

*puts on flame retardant clothing*
Logged
jonoerik
Champion
***
Posts: 196



View Profile
« Reply #7 on: June 29, 2010, 12:45:16 AM »

Shouldn't have said curses specifically.  Just meant terminal / console output.
Not a serious idea really, but if we're competing with curses...
Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #8 on: June 29, 2010, 02:48:34 AM »

(edit: oops, long post -- this is exploring the possibility of a libtcod client to play remote games, like telnet/ssh.)

I think I got jonoerik's main point; it's not necessarily "a curses port", it's a pure terminal renderer. (Although there's not much of a difference...) But anyway, you can get much more beautiful output with the current system, by selecting a good font (look, there's anti-aliasing!) and restricting your colors. And instead of those pure colors that make your eyes bleed, select some paler versions for good measure. And it's SDL, it's the most portable thing ever!! The only thing going for a pure terminal renderer would be the easy networking. But then...

I think a much more plausible approach would be for someone to make a generic remote console (the client), using libtcod, with a simple protocol over TCP-IP, and distribute a library with simple commands so any program can interface with it (the server). Then you could set up a server and anyone can play remotely using the client program. It would be kinda cool, since potentially the same client could play many different games, and it would enable contests and fair leaderboards since cheating would be impossible (those are, I guess, the main points given by curses proponents). Also the client is libtcod so no ugly colors and fonts. But this is a project orthogonal to libtcod.

However, instead of making this set of remote rendering functions into a separate library, it could be seen as just a different renderer -- though it sends the console state through TCP/IP instead of rendering directly to the screen. THAT would be nice, all the advantages of libtcod (awesome rendering) and all the advantages of curses (remote client). But that's only assuming you value this "remote client" stuff highly; personally, I don't care much for it, I'm happy downloading a game and playing it locally Smiley
« Last Edit: June 29, 2010, 02:50:58 AM by Jotaf » Logged
mingos
Global Moderator
Master
*****
Posts: 583



View Profile WWW
« Reply #9 on: July 02, 2010, 12:12:35 AM »

Do you guys remember libtcod's motto from the early versions (1.1 and such)? The website was still on googlepages (googlesites didn't exist yet) and Jice used a simple banner in the page's header that had two "screenshots" from a hypothetic roguelike, one in 16 colours and one with a nice light source, with a coloured background fading farther away from that light source, and with a mob (presumably a rat) in the corner, rendered in dark brown as it was far away from the light. And there was this motto: "Bring colours to your roguelike". This is the point of libtcod. A TRUE COLOUR console emulator - something neither curses nor any terminal can do.

My point is that if you need to use the terminal, there are tools designed specifically to handle that. You can still adapt libtcod's code and use what's not related to the display in your own app.

Also, libtcod doesn't compete with curses. It's like saying that "Volvo competes with Husqvarna". They are meant to do different things, so they can't be considered competing products Grin.
Logged

If debugging is the process of removing bugs, then programming must be the process of putting them in.
- Edsger Dijkstra
jonoerik
Champion
***
Posts: 196



View Profile
« Reply #10 on: July 02, 2010, 12:38:37 AM »

Also, libtcod doesn't compete with curses. It's like saying that "Volvo competes with Husqvarna". They are meant to do different things, so they can't be considered competing products Grin.
That could be true, but I think that a lot of people would have gone with curses if they hadn't found libtcod or a similar library.  I was going to get into curses development, but then I found libtcod.  Most people just start with wanting to put characters on a grid, and that range encompasses an exceptionally wide variety of libraries.  A rake and a leaf blower may be 2 completely different tools, but they have shared applications and therefore probably compete for the same customers (more so than Volvo and Husqvarna).

The concept of curses in libtcod was also meant to highlight just how far the library has come from those simple beginnings.  Just how much Jice has improved on the original concept.  We couldn't possibly go back to anything with less than true colours.  So I'm going with satire on this one; and the original post wasn't a serious suggestion anyway.

this is exploring the possibility of a libtcod client to play remote games, like telnet/ssh.)
The post wasn't about the concept of remote games, but a remote libtcod client does sound like a good idea.  I'm not sure how useful it would be, but the main applications would be allowing people to try out a variety of roguelikes without downloading them all.  The gallery of current libtcod games could become playable with only a single download.  This is probably a more valid avenue of discussion, so lets talk about this...
Logged
jice
Administrator
Master
*****
Posts: 1456


View Profile WWW
« Reply #11 on: July 02, 2010, 09:52:53 AM »

To make it perfectly clear : libtcod won't support an official curses renderer. But what could be done is to allow third party renderers through a well defined renderer interface so that you could create a libtcod-curses-renderer.dll. This would also make it simpler for people to work on GLSL or OpenGL renderers without having to deal with the messy libtcod internal code. But it does not look like something easy to do...

Why not supporting natively curses ? Because of the philosophy behind the Chronicles of Doryen. The whole project was triggered by a finding :
Roguelikes are insanely deep and have huge replayability, but roguelikes as they have been done since 20 years suck. They suck as vi suck. While this sounds really trollish, it's not. By "suck", I don't mean they're good or bad, I mean they're not adapted anymore to most nowadays users. Of course, there are still a lot of people using vi or vim (a good proportion of them being the one who used it back in the 80s), but most people have moved to more intuitive editors like UltraEdit, Pspad and so on. Note that more intuitive is not necessarily more powerful. Fortunately, most of the new text editors that are released nowadays have a user friendly interface with well known conventions (like shift-arrow to select or clicking a File/Exit menu to exit). Nobody can use vi the first time without reading carefully its man page. But download any recent text editor and you can use it out of the box.

That's not the case with roguelikes. They never moved away from the first design. If text editors had followed the same path as roguelikes, you would still have to use some alien key combination like :q! or Ctrl-X-Ctrl-C to exit the editor and memorize a load of key shortcuts to be able to do basic operations like text selection or clipboard operations.

The one and only goal of TCOD is to try to trigger a new generation of ASCII roguelikes that get rid of the roguelike tradition and use modern gaming conventions instead (who needs a manual in nowadays games ?). One of modern gaming convention is that video game should be visually appealing because nowadays gamers are lazy and won't invest time in a game if it does not look hot. In that perspective, providing a curses renderer would be counter-productive.
Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #12 on: July 02, 2010, 05:24:45 PM »

Amen to that, Jice! Grin

Anyway the conversation shifted a bit towards a libtcod client (just to be clear: with TRUE COLORS of course!) similar to telnet/ssh, except with a new protocol specific to its rendering and input capabilities. Then you could run a server and host games. This concept may have some overlap with the recent discussion of multiplayer RLs. Except a "dumb" console probably wouldn't support cool animations at all Lips sealed
Logged
jice
Administrator
Master
*****
Posts: 1456


View Profile WWW
« Reply #13 on: July 03, 2010, 05:36:18 PM »

Concerning the "remote play" offered by telnet :
* it makes it possible to play the game without downloading it.
So what ? Most roguelikes don't exceed 1MB, nobody cares about downloading and unzipping that nowadays... If I'd really want that feature, I would use a web language like javascript instead of developing a client-server framework where you still have to download and unzip a client anyway.
* it makes it possible to have a centralized score board.
Well, using telnet for that is really wrong. The right way would be to send the player score to a web server through http and have a nifty web page to display the board (or again, use a web language and have the roguelike directly on a web server). We're in 21st century !
* it makes it possible to have multiplayer RLs.
I think trying to add sound and network support directly in libtcod would be wrong. First, they're both huge and complex domains and there are already good free libraries for that (FMod for sound and OpenTNL for network)
Logged
jonoerik
Champion
***
Posts: 196



View Profile
« Reply #14 on: July 04, 2010, 10:54:53 AM »

--Admittedly, most people don't mind downloading such small files.  I think the main advantage here is that people would download the client to play one, or a few roguelikes they are genuinely interested in, but would also try out other roguelikes while they have the client.  There are plenty of probably quite good roguelikes in libtcod's catalogue that I haven't tried simply because the screenshots haven't got my attention.  Think of this as an easy way of offering people roguelikes that they don't even know they want.
--Perhaps telnet isn't the correct way of going about a centralised scoreboard, but it would have an advantage over simply sending player scores in; it would be harder to cheat a highscore by sending non-authentic score information to the server.
--Again, libtcod probably shouldn't have networking or sound support included.  It is your library Jice, so you include/exclude whatever you want.  Those 2 features would probably detract from the focus of the library, and there are a number of good alternatives available.

The above points don't make remote roguelikes a good idea though.  Telnet isn't really suited to what roguelikes do anyway, especially the true colour ones.  I don't know much about it as a protocol, but you'd be better with something a bit more general for this type of information transfer.  Having everything networked wouldn't be as elegant, or as simple, or as efficient as a traditional roguelike setup, but someone's got to try it.  Think of it as a challenge!

As for the original post, it was meant to be tongue in cheek.
The above post is not to be taken seriously under any circumstances!
Libtcod would look rubbish without true-colours.  Our roguelikes however, shouldn't just rely on good graphics to stand up as games.  A core concept of the roguelike genre (at least in my opinion), is that the games compensate for their lessened graphical appeal by having really outstanding gameplay and replayability
« Last Edit: July 04, 2010, 10:56:42 AM by jonoerik » Logged
Pages: [1] 2
  Print  
 
Jump to: