* Tuomas Huhtanen
> I would use different threads based on settimeout, but the
> synchronization would be done by the date.
got it. sounds like a pretty sound idea. I'll do some testing with
the timer library to see how it performs under load. problem is that
when it snaps, it'll do it in 55ms
Just uploaded part 2 of the tutorial. Already have finished the first 5
parts,
and the game is currently looking very good (and smooth on both IE5+ and
Mozilla) with bullets and monsters flying around (currently using about 15
layers)
This 2nd part adds a player object to the scenery, and adds mo
> the Date() object should be fairly accurate since its creation doesn't
> take any mentionable time. I don't really see how you can create
> something that'll work with it though, since the only tools you have
> for forking (which is required to get the screen update) is
> setTimeout() and setIn
* Tuomas Huhtanen
> I'd be really interested to see this scheme in action...
anyone may feel free to drop by http://www.treemenu.com/morten/timer-lib/ > download the .zip and play
with the code to see if it works or not.
> Depending how you wan't to synchronize your threads, trusting the
> timer
> Some interresting testing, true, but what your trying to improve
> IS already
> good. (NT)
> The problem is that windows/IE has a minimum timeslice of 55ms (or so)
> compare to 10ms for other operating systems.
> Theoretically halving this would allow for smoother animation, on windows
> only mi
Hi,
Some interresting testing, true, but what your trying to improve IS already
good. (NT)
The problem is that windows/IE has a minimum timeslice of 55ms (or so)
compare to 10ms for other operating systems.
Theoretically halving this would allow for smoother animation, on windows
only mind you.
A word of warning in the beginning, this might get lengthy...
I'd be really interested to see this scheme in action, since I also can't
quite see the benefit of this scheme using the threads/timers based
synchronization and/or to gain performance boost. It's not that I don't
believe in that, but
pardon me if we're moving off-topic for dynapi-help here. I don't
want to step on too many toes discussing something that may not
concern DynApi2 all too much, and I'll happily let the thread die if
it's drifting too much.
* Pascal Bestebroer
> Is there any point in this?
in my opinion: yes. i
> IMO, I think it's probably more sensible (at this stage in
> time) to look
> upon the 18.2Hz tick as a fundamental constraint to build DHTML games
> around, rather than try to fix the whole platform via
> multiple threads.
I think it's the only possibility. The setInterval is the javascript tim
>Is there any point in this? if your code can't execute within
>the time of the first timeinterval.. it can't possible run in
>both intervals..
This would only be for code that requires smoother animation than 18.2Hz
(which isn't particularly smooth, coming from a games point of view).
>if you
I've never given much thought on the timing subject so still
a bit in the dark here..few questions that popped in:
Is there any point in this? if your code can't execute within
the time of the first timeinterval.. it can't possible run in
both intervals..
or are you splitting up your code so th
ROTFL
Sorry... this is embarrassing.
Nice to know that the community is so well connected :-)
Stephan
___
Dynapi-Help mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-help
> You probably have already read this article:
>
> http://www.webreference.com/dhtml/column28/
LOL
I definetly think he read that article (check the author :)
Pascal Bestebroer ([EMAIL PROTECTED])
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com
___
> I've only done performance-testing with a single layer, to identify
> the timeout problems.
You probably have already read this article:
http://www.webreference.com/dhtml/column28/
Stephan
___
Dynapi-Help mailing list
[EMAIL PROTECTED]
http://lis
* Pascal Bestebroer
> anything you can share already ?
>
> logics would be fine...
> ...code would be great :)
code will come. :)
> although I think that the main problem is not the speed of the interrupt
> but more the speed of browser-rendering.
I've only done performance-testing with a sin
> > I've worked with lots of programmers on lots of games
> > projects, and would have to disagree - just about all of them push the
>limits on
> > each game in one way or another... that's part of the whole process.
>
>maybe for console games, but I don't think PC games are really getting the
>a
> I'm currently working on a followup article to this one (after all
> it's been 18 months since I wrote it) where I'll give insights and
> code for an improved timer solution I wrote about a year ago.
> multithreading has for me given better results. I'll need to clean
> the code a bit before th
* Nick Pelling
> As a game-writing veteran, I've tried doing some simple animation using
> DynAPI: however, the frame-rate seemed limited to about 20Hz - I
> couldn't get it any smoother than that on my mid-range PC. That was
> moving a single small layer on a screen with about 37 layers, which is
> I've worked with lots of programmers on lots of games
> projects, and would have to disagree - just about all of them push the
limits on
> each game in one way or another... that's part of the whole process. Maybe
> that's a UK development thing: but it's very real nonetheless.
maybe for consol
> > FYI: I've been writing games professionally since 1982, and
> > have career
> > sales of between 3.5 million and 4.0 million units. :-)
>
>sounds nice..but that doesn't make you a creative programmer ;) I think
>there aren't many left in the industry at this time.
However many there were, t
> Many/most mid-to-late C64 games (I wrote a good few myself) used
> sprite-plexing to achieve 30+ sprites on screen at one time -
> that was when
> that C64 games got quite interesting. So: 16 or less isn't
> entirely true.
I remember games like Turrican and games from the Rowland brothers
(Crea
>I would disagree on the 37 layers for a game. My game-coding experience
>started on the C64, where you could have maybe around 16sprites on screen
>at once..and that was enough for solid action games.. (usually less)
Many/most mid-to-late C64 games (I wrote a good few myself) used
sprite-plexi
At 20:01 09/07/2001, you wrote:
>To check out what his library can accomplish, play the Supercollider game
>which he
>programmed. Excellent stuff.
Or my reflexes are very poor (but hell, I Quake or StrikeForce all the time
:-)), or my computer (Duron 700@770) is too fast for this It is
un
> I placed another article on my site describing some does and don'ts when
> doing dhtml-game coding.
Pascal, thanks for constantly evangelizing for DHTML.
Your game will make an interesting test case for every api (including
mine ;-).
Waiting for the complete game to show up...
Stephan
___
I wonder if any of you have checked out Scott Porter's wonderful DHTML game programming
library called gamelib at www.javascript-games.org. Just go to the link at the bottom
right of the main page. He also has many DHTML games on his site.
To check out what his library can accomplish, play the Su
7;s out there (some exceptions ofcourse).
...
Pascal Bestebroer
[EMAIL PROTECTED]
http://www.dynamic-core.net
:-:-Oorspronkelijk bericht-
:-:Van: [EMAIL PROTECTED]
:-:[mailto:[EMAIL PROTECTED]]Namens Nick Pelling
:-:Verzonden: maandag 9 juli 2001 18:32
:-:Aan: [EMAIL PROTECTED]
:-:Onderwerp:
I've just released
the first part of a DHTML game-writing tutorial, the
tutorial
will walk thru the
game writing step by step showing example code and
explaining
why things are
done.
The idea is to
show how you can create real arcade style games, and not
another
4 in a row, or
mineswee
27 matches
Mail list logo
