Messages

16

Programming / Re: OS X/Linux/Unix/etc Compatibility

« on: March 22, 2012, 08:37:33 PM »

Short answer: No.

(Also, .exe is a Windows executable file, nothing to do with unixes).

17

Programming / Re: Unicodetiles.js: JavaScript character tile engine

« on: March 22, 2012, 08:35:15 PM »

@yam655:
I have considered Android. I have an Android smartphone with HW keyboard myself, which made me add HJKL keys to the demos because the phone doesn't have usable arrow keys. I have also thought of creating some custom touch control widget, but nothing on the implementation side yet.

Regarding the fonts you mentioned, I encountered both FreeMono and Unifont when I searched for a suitable monospace font to bundle. I don't remember what turned me from FreeMono, perhaps the lower amount of glyphs. Unifont on the otherhand appeared very blocky and at least some glyphs were not monospace. I guess I could try updating the engine to support non-monospace fonts, but that's not high on the TODO.

18

Programming / Re: Unicodetiles.js: JavaScript character tile engine

« on: March 15, 2012, 02:42:54 PM »

Do you have any interest in the advanced level for Closure compilation? I don't think it would require too many changes to the code?

I actually tried it with Infiniverse by exporting the starting function and then posting everything (game sources, unicodetiles and jquery) to closure compiler, but it didn't work. I'll probably revisit it in the future, but currently I have much better things to do now that the 7DRL Challenge is ongoing.

19

Programming / Re: Unicodetiles.js: JavaScript character tile engine

« on: March 14, 2012, 08:44:08 AM »

I've started to implement my 7DRL with Unicodetiles.js as planned. You can read a status report here: http://7drl.org/2012/03/14/infiniverse-js-7drl-status-report/

The development has spawned several bug fixes and additions back to this library. \o/

20

Programming / Re: Unicodetiles.js: JavaScript character tile engine

« on: March 06, 2012, 01:28:42 PM »

So I spent the afternoon testing HTML5 <canvas> element with unicodetiles.js. Surprisingly I got it to a rather nice state quickly and I already published a new version that has both the old-skool DOM renderer and the new canvas one. The default behavior is to try to use canvas and fallback to DOM. But this can also be changed and even switched on the fly (!) as can be seen in the revised examples.

The canvas renderer doesn't (yet at least) produce pixel perfect copy of the DOM one, but the performance rocks. In the stress tests (that can be found from the tests subdirectory) I get speed factors from 2x to 7x depending on browser and test. Firefox has the greatest benefit, as the DOM version is awfully slow on it.

21

Programming / Re: Unicodetiles.js: JavaScript character tile engine

« on: March 01, 2012, 02:44:27 PM »

Firefox looks like the font is not monospaced. It is the school library computer so someone might have done something.

Perhaps your school has a really ancient version of Firefox, because it works for me with FF10 and even on FF 3.6.27 I quickly tried. Web fonts are not supported below FF 3.5

22

Programming / Re: Unicodetiles.js: JavaScript character tile engine

« on: February 26, 2012, 01:52:51 PM »

2) I'm actually currently revamping the input stuff based on comments I got in IRC. 150 is basically a good (IMO) movement delay for continuous movement, but it's used for other things, which make it a bit broken. However, that's more of an issue with the examples than the engine itself I think, as everybody is free to implement the moving however she wants.
3) Good idea, I'll test how that looks

This is now done. The input module can now do custom key repeating, i.e. there is no initial delay and the interval of the events is customizable. For the examples this means that there is no missed key presses, the movement is instant, and holding a key down does not cause a long initial delay.

It works nicely in Chrome and Firefox. Opera has some weird bug that it looses the delay after a sec and goes full speed. For IE9 the keys might get stuck down in Infinite Forest for a while, but that might be because I only tested IE9 on a low powered netbook, which kind of chokes on that example.

23

Programming / Re: Unicodetiles.js: JavaScript character tile engine

« on: February 23, 2012, 08:02:43 AM »

I very much like it.


Curious questions
1) Why do you "use strict" within each function instead of once at the top of the .js file ?
2) Why do you use    window.setInterval("tick()", 150); in the simpledungeon.js , the engine shows off much better with a tick value of 50
3) Your demo really should use the old fashioned block character to show the unicode part of your engine ( ▒ )
4) The engine is too slow at 120 by 50, but I think with some tinkering, it should run great at mapsize as well.

I looked at the code, oh my, you love commenting, which is great

T.

Thanks for your comments.
1) I read somewhere that global "use strict"; might break third-party libraries and JSHint code analysis tool doesn't allow it by default.
2) I'm actually currently revamping the input stuff based on comments I got in IRC. 150 is basically a good (IMO) movement delay for continuous movement, but it's used for other things, which make it a bit broken. However, that's more of an issue with the examples than the engine itself I think, as everybody is free to implement the moving however she wants.
3) Good idea, I'll test how that looks
4) I've actually tried to do quite a bit of optimizing, but didn't yet try with that big viewport. Enabling the tile caching feature might speed up things a bit, but it's already enabled in the forest example. The thing is that the DOM just is rather slow. If it really starts to become a problem (my 7DRL will probably be rather computationally intensive), I'll implement a canvas renderer.

24

Programming / Re: Quadtrees?

« on: February 23, 2012, 07:36:24 AM »

Well, in quadtree, every non-leaf node has 4 children and their arrangement is usually spatial, so quite different from binary tree. Quadtrees (and octrees, their 3d counterpart) are useful for level-of-detail stuff (mainly in 3d graphics and terrain rendering: for parts close to the camera you dive deep into the quadtree branches and far away parts of the scene can be left to higher levels) and data compression (e.g. if you have a large area of water, you could represent a big part of that as a big quadtree node and then subdivide i.e. create finer grained cells when there is an island).

You could also put something like enemies to a quadtree which would allow searching for them in a specific area very efficiently since a quad tree can potentially tell you very early that there is no one there (or alternatively "zoom-in" to the targets quickly). However, this really only becomes beneficial with a huge map and lot of stuff to search. In the context of fairly traditional roguelikes, I don't really see use for quadtrees - array is much easier to work with.

25

Programming / Unicodetiles.js: JavaScript character tile engine

« on: February 22, 2012, 11:37:17 AM »

Unicodetiles.js



I'm going to make my 7DRL a browser game and I thought it could be nice to share my JavaScript library I'm using for displaying the character tiles. I'm deliberately avoiding the word ASCII, because the engine has a monospace Unicode font bundled, so every user will also see more exotic characters consistently.

The engine is based on pure text and DOM, so there is no <canvas> (nowadays there is a canvas renderer, which is also the default one), WebGL, Flash, Unity or anything like that involved. I aim for compatibility so it should work on latest versions of any major browser. A bit older ones are also fine, but IE8 and below appear to have too slow JavaScript/DOM for this to be usable.

You can read more about the features from the webpage: http://tapio.github.com/unicodetiles.js.
I've also tried to document it and there are several examples available. Some of the examples build upon others so they could almost be regarded as tutorials. Note that even though the demos produce roguelike lookalikes, the library itself is for displaying stuff and does not contain e.g. dungeon generators or FOV algorithms.

I was actually toying around with the idea of changing the API look like libtcod, but I think I'll leave it as it is at least for the 7DRL. Anyway, if anyone should like to use this as a basis of libtcod JS port, feel free: it's MIT licensed.

26

Programming / Re: BSP Difficulty

« on: July 27, 2010, 05:03:16 PM »

Yes you can. You just misused the syntax, it should be:

Code: [Select]

private:
BSP *m_parent, *m_sibling, *m_childA, *m_childB;

or less error prone:

Code: [Select]

private:
    BSP* m_parent;
    BSP* m_sibling;
    BSP* m_childA;
    BSP* m_childB;


27

Programming / Re: Version control

« on: June 27, 2010, 03:30:08 PM »

Strange; i always thought branching was super fast (of course without checkout) since it's just some sort of hardlink to a svn-revision. Maybe i'm incorrect; i'll check it out at work.

Yes, svn seems to do some hard-linking in the server side, but a checkout is still needed for working on the new branch, right? And client side doesn't use linking? Anyway, maybe I gave a bad example of git's and svn's differences, since I guess it isn't the most relevant thing to newbie users.

A few things I don't like with svn is how it doesn't seem to give any indication of progress - checkouts/updates just spam the file names to the terminal without telling how much is left, whereas git clone/pull gives a nice percent count (on top of usually being much quicker) (don't know/remember what hg does) (if you know some switch to change svn's behaviour, I'm all ears). However, the main thing I like about distributed systems is the lack of network latency: I tend to e.g. check the log quite often and see diffs of old revisions and with DVCS, those are just instant whereas with svn, I got to wait - sometimes just a little, sometimes seconds - and even though that might sound small, after you've gotten used to instant, seconds feel like ages.

EDIT: Also, git-log goes straight to less/more-like scroller environment, with latest commit right on top there to see, whereas with svn I usually end up striking ctrl+c to get the horrible log spamming to stop and then I need either to scroll back the terminal to find the latest stuff or re-run, piping to less or head or whatever (this is using command-line of course).

28

Programming / Re: Version control

« on: June 26, 2010, 05:08:54 PM »

One thing fundamentally different with svn and git is that svn branches are just copies of the directory (and tags are read-only copies), whereas git (and I believe Mercurial also) repository is a "pool" of commits and branches + tags are just pointers to certain commits. This leads to smaller repo size and super-fast, very cheap branching.

You mean "super fast and cheap branching" in svn, right?

If you have a large project, copying the files to make a new branch in svn can take some time. Also, at the same time you double the disk space usage. Git branch is a 40-byte text file that contains the commit id of the branch's HEAD. That can be generated in negligible time (and uses effectively no additional disk space - of course additional commits to the branch start to take some, but it'll be a while until it is close to duplicating the files). Of course if you have the svn branches already checked out, switching is just changing directory, whereas git needs to patch some files.

A note though: with git, you are also free to use svn-style branches. You can have the project git-cloned multiple times and if you wish to merge stuff, just git-pull from the other repo.

29

Programming / Re: Version control

« on: June 26, 2010, 10:33:17 AM »

I use git and love it. However, I haven't really heard anything bad about Mercurial (they say on Windows it is better, but I haven't have any problems with git either). Historically git might have been a bit hard to learn, but those times are long gone. Git gives quite verbose output from its commands, including hints about what you might want to do next, whereas Mercurial uses e.g. svn-style status info, which is very compact. The basic commands work almost identically in both git and Mercurial. In any case, distributed version control system is the way to go (third option in that category would be Bazaar (bzr), but it is not as widely used and much slower than git and hg).

One thing fundamentally different with svn and git is that svn branches are just copies of the directory (and tags are read-only copies), whereas git (and I believe Mercurial also) repository is a "pool" of commits and branches + tags are just pointers to certain commits. This leads to smaller repo size and super-fast, very cheap branching.

Here's some things why I use VC for lone projects also:
* Branching - I can do something experimental in a separate branch (e.g. test SFML instead of SDL) and also continue work on the "stable" and then if I decide experimental stuff is good, merging them together is easy.
* Sense of going forward - commits show that I've managed to to something.
* Generate changelogs.
* Find out where a bug was introduced by using half-automated (could actually be fully) git-bisect binary search on the commits.

30

Traditional Roguelikes (Turn Based) / Re: Teemu v1.1

« on: May 21, 2010, 08:48:13 AM »

By the way, one guy "valgrinded" Teemu and found a leak, but he refuses to tell where it is. That's a bit gay. I don't have any memory leak tools, because I'm using free edition of Visual C++. It's probably nothing too serious, because the game seems to work ok and doesn't crash.

It's probably this one: http://pastebin.com/Y66CFd4r
There were a couple of other errors, but they seemed to originate from SDL.
(Also, for education, DLLs are called "Shared Objects", .so in *nix world.)

EDIT: rerun with debug symbols, so the output is more useful