Menu

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.

Show posts Menu

Messages - Denzil Quixode

#81
Quote from: iCyborg on Wed 09/02/2011 13:11:31
Tested again in Firefox 4.0 Beta 10, don't know why but the result looks good/better now:

Because I changed it := I switched Windows into 16-bit colour mode and started getting the same result you did, realised what was going on and altered the code to work around it. (However, Wyz reports that doing that has broken it in Chrome for him, but I still haven't managed to reproduce this...)

Quote from: iCyborg on Wed 09/02/2011 13:11:31
*Also tested in Firefox 4.0 Beta 11 [latest beta at this moment] but no go: "Could not initialise WebGL, sorry :-("
Tried to reactivate WebGL using 'about:config';: no result.
Hmm, can you see if you can run any WebGL things? Possibly I'm trying to initialize it wrong or something.
#82
Really? Damn... I can't reproduce that, it looks OK to me on the latest Chrome 9 (I just updated, no difference) in both 32-bit and 16-bit color mode. It's probably unlikely to be this but could you try a Ctrl-F5 hard refresh? Just in case...
#83
Thanks for the report. I have modified the technique, could you try again and let me know if it is any better now?
#84
Great to hear, thanks guys.
#85
I am experimenting with WebGL rendering. WebGL looks very cool but is only available in the bleeding-edge beta preview versions of Firefox 4 and Chrome 9 at the moment.

If you have one of those (you can get the Chrome 9 beta from http://www.google.com/landing/chrome/beta/ or Firefox 4 beta from http://www.mozilla.com/en-US/firefox/beta/), I'd appreciate it if you would try this page and tell me if you see two of exactly the same image, or if there are any graphical glitches/other problems:

http://octospherics.com/toolbox/webruntime/paltest.html

The left side is a normal image, the right side is a WebGL-rendered version using a shader to simulate 8-bit palette mode.

Edit: I have a second test page now with some simple palette effect buttons. I've no idea why but on Chrome you may need to click them a few times before they will work (Firefox doesn't seem to have this problem):

http://octospherics.com/toolbox/webruntime/paltest2.html
#86
You also need it for script modules that you'd like to be able to easily export and import as self-contained files.
#87
Quote from: benco on Tue 18/01/2011 12:28:15
First of all, as everybody said: Congrats !  ;)

You were the fastest ha ha  ;D ... I was planning to make an adventure game engine in html5/js. I had begun collecting resources last year and AGS (that's still my favourite engine) was in my opinion the best candidate to analyse (api requirements ...) for my first experimentations.

I took a look at your js code. Indeed, it's a really incomplete engine but there are nice stuffs all the same (in my case, I wasn't planning to base all on canvas but also on imgs-areas-maps but it seems to rock anyway) !
I have been wondering about attempting a really retro-DHTML renderer that doesn't need Flash or HTML5, just works with absolutely-positioned <img>s and <div>s and stuff. It wouldn't be able to do everything, but for a particularly simple game it might be enough. It's hard to imagine there are really that many people left who would benefit from it, though...

QuoteJust about the music and sounds:

* On mobile safari, there is currently a bug that impede playing more than one sound file at the same time and I don't know when they plan to fix it :(
Crap, that is annoying. I suppose the solution is to do some (ugly) browser-sniffing and then ensure there's only ever one audio file playing at once...
Quote* I think when the new mozilla audio api will be popularised and used , it will allow playing more audio formats - a bit like new flash 10 stuffs allow now. And there are already experimentations done about Amiga MODs playing what is really awesome: you might take a look at the dynamicaudio.js library and the jsmodplayer project on github, it's really interesting
Cool, yeah, very interesting stuff. I am trying to make the audio system modular so it could potentially use several different ways of playing sound in the same game, depending on the formats the game uses and what plugins/features the player's browser has.
#88
Quote from: straydogstrut on Fri 14/01/2011 07:14:15
Tried it last night, but just tried it again now: no joy I'm afraid, unless I've done something silly. It's a 4th gen iTouch running Safari if that makes any difference. I wouldn't worry too much about it though.
Ah, thanks anyway. As I understand it Safari does support <audio> but only for MP3s, not Ogg Vorbis, and that seems to be the case in my (desktop, Windows) version of Safari. I don't know how different the mobile version of Safari is, or whether it lags behind in the feature set, or what.

Quote from: tzachs on Fri 14/01/2011 13:43:49
Specifically the flash port would be most useful in order to get AGS game distributed to portals.

It might not be as easy as that - even in Flash mode, it really is still JavaScript running the show. The Flash part is a tiny 10kb "renderer" SWF that knows nothing about any of the game logic and simply displays what it is told to by the JS. I assume that what the portals want is a single, self-contained Flash file.
#89
Thanks sds :) Would you mind trying the MP3 version on your iDevice to see if the audio works then?
#90
Okay, I've quickly made an MP3 version of the demo:
Web Runtime Demo: MP3 edition
Chrome/Chromium and Safari should play MP3s in HTML5 <audio>, but everything else will probably require Flash to play audio in this version. I made the Flash MP3 player very quickly today and it might have some bugs still, but it does support crossfading and track mixing.
#91
Quote from: kaputtnik on Thu 13/01/2011 14:45:42
Feedback time!

I've briefly tested the Java version on all browsers I have installed (2,2Ghz Dualcore Thinkpad, Linux Mint) and had very different results concerning audio and game performance. The best choice seemed to be Chromium, though.
Thanks very much for your report!
QuoteChromium: Game runs smoothly, audio performance is pretty good, no stutters - but audio files are always cut off something like a second before they have finished playing.
Hmm, interesting. The <audio> output should be using the 'loop' parameter to loop audio (except Firefox, which doesn't support it for some reason - I set up a dirty hack to detect this and use a JavaScript timer to check whether the sound has finished playing every quarter of a second...) so it sounds like it may be a Chromium bug.
QuoteFirefox: The zoom looks good and crisp (as you mentioned), audio stops after spending some seconds in a room and only starts playing again when you change the room (although sometimes it doesn't)
Ah, maybe my dirty hack didn't work so well then. And I have no idea why a new audio track just wouldn't start up at all. :P
Quotethere is also a pretty heavy lag when leaving a room.
That might be the walk-behind buffers being redrawn, not sure...
QuoteOpera: Really heavy graphics lag when leaving a room, funny colour confusion (if a conversation spans over two lines, they appear in two different colours, the @OVERHOTSPOT@! text will sometimes be displayed in blue or green tint, hovering over dialogue options tints them green.
This is very interesting - I don't think I ever noticed any such graphical glitches when I tried it in Opera (11.00 build 1156, Windows). I'm relying on the 'globalCompositeOperation' property of <canvas> to colour the text, I'm not sure there is much I can do if a browser doesn't seem to support it too well.
QuoteOpera had the best audio performance, it never so much as stuttered and the files played nicely to the end (even though they didn't loop seamlessly, but you already mentioned that issue)

Midori: Audio stops from time to time, heavy lag when leaving a room, but none when entering. Game runs pretty slow. I realize that maybe 8 people in the world use Midori as a browser on a daily basis, but I had it installed, so I wanted to mention it...
I had never heard of Midori before, I'll have to look into it. The more the merrier!

QuoteMaybe you can use some of this feedback - I guess audio handling and performance is still the weakest spot of your proof-of-concept, but this is probably because of the script necessary to play .ogg files. If you want, you have my official permission, as creator of the soundtrack, to convert from .ogg to .mp3 for test purposes.
Thanks :) I might do that soon as a separate page to see what the comparison is like.


Edit: Ha, I just tried it on Midori 0.2.6 for Windows and the graphics seem to work fine - except that it ignored the width and height I gave the canvas, so it remains a cropped 300x150 pixels...
#92
    Quote from: Ben304 on Thu 13/01/2011 08:14:26
    Very impressive - aside from music issues I played through the game without noticing any gameplay or presentation glitches at all.
    Thank you! These are the music issues I know about, let me know if you are talking of ones that are not covered:

    • Flash mode does not have crossfading or seeking due to technical reasons. Flash does not have native Ogg Vorbis output, and I decided that I did not want to transcode MP3 alternatives for this demo - so this is actually running an Ogg Vorbis decoder written in Flash code itself (actually in haXe, but compiled to Flash). This is also I believe why there may be a noticeable pause whenever the track changes in Flash mode - it's doing a lot of work.
    • Opera seems to keep the previous track playing for too long when crossfading tracks. I am unsure whether this is something I am doing that happens to not affect other browsers or if it is an actual bug in Opera.
    • Safari supports the HTML5 <audio> tag, but does not support Ogg Vorbis to be played through it, only MP3. Most other browsers are the opposite way around. Helpful...
    • The music doesn't go quieter for a bit after the rap battle. I just plain forgot to support this.  :-X
    QuoteIt's hard to deny that the open-ness of the code could be a sticking point, but for the most part I think it'd be preferable to not being able to put the games in a browser at all. The ability to run games in a browser overshadows, for now at least, protection of one's assets - particularly in smaller freeware games.

    That is what I am hoping. It is always going to be up to the individual to decide, before anyone starts getting worried that this could ever potentially be forced on their games - even though I have called this the "web runtime" demo (because of that other thread), it really isn't a runtime like the existing Linux or Mac runtime projects - you would not be able to use it to run compiled games, you need the original source code to convert a game to be able to run on this. So unless you have released the source to your game, in which case anyone can see the scripts/resources anyway, you are the only one who could make that decision.

    But maybe it will be possible to make something that runs server-side: node.js is a project for running JavaScript on the server, on Google's highly advanced V8 JIT JavaScript engine; Socket.IO allows two-way communication between client and server; and I know there are projects out there to allow node.js to use jQuery and Canvas, which could conceivably all be put together to run this same code on the server and transfer image data to the client. Whether it could be fast enough, and how many users it could actually sustain at once, are the big questions. I have no plans to try doing this myself, but maybe someone else could do their own proof-of-concept...

    QuoteI'm interested in a couple of things -
    Okay...

    • ability to scale beyond manually doing it with browser zooming features
    The HTML5 specification quite specifically does not allow you to control how a bitmap image is scaled, which means that if you scale something up to 2x using <canvas> features rather than browser zoom, the result is most likely going to be exactly the same. And it really is too slow to do it manually pixel by pixel, in real-time at least.

    Mozilla has a proprietary CSS extension which allows you to specify that an image (or HTML5 canvas) should be rendered with sharply-edged pixels rather than that kinda blurry filtering. This is actually used in the demo, which is why it should always have nice sharp pixels when zoomed in with Firefox, but no other browser.

    Flash has the advantage here. With Flash you can both specify that you want something rendered without smoothing, and Flash 10 also has Pixel Blender which allows you to run pixel shaders that I believe could be used to do some advanced pixel art scaling algorithms in real-time.
    • support of things such as alpha channels
    Alpha support is as far as I know is very good, for both Flash and Canvas.

    Tinting looks much much easier to do in Flash than Canvas, though.

    • the actual conversion process
    While the process in this case was mostly manual, I have not done anything an editor plugin could not do automatically (I think...). The scripts are transformed using a C# AGS-Script parser I wrote myself, the images and fonts are all exported as PNGs (and packed into a single image using the (C#, MIT-Licensed, open-source) Sprite Sheet Packer). I even decided not to have MP3 alternative versions of the Ogg Vorbis music, even though that would make it far easier to play on Flash (and Safari's <audio>), because transcoding music from one lossy format to another is a process that I feel the user would need to control and consent to.

    • eventual support for saving/loading
    All I can say at the moment is, I don't think it would be that difficult to get the game saving and loading to a JavaScript string, and from there whatever weird and wonderful methods people want to use to store and retrieve those strings can be written around it. I'll know more when I actually try to do it :P

    • support for accessing other external files aside from save files (such as, but not limited to, translation files and running other .exes from )
    I actually don't know much about translation files yet.

    Other .exes, no. Other games similarly converted, yes, most likely.

    • support for plugins (such as, but no limited to, ogg theora player)
    Well, my idea is that you should be able to customise the export process so that you can supply alternatives yourself for resources like music, video and so on, and this could of course support formats that are not supported by the original AGS engine.

    Also, I have ideas that you should be able to do things like this in your AGS code:
    Code: ags
    
    #ifdef WEB_RUNTIME
      WebRuntime.CallJavascriptFunction("alert", "Hello World!");
    #endif
    

    ...so customisation of the web version of the game could be endless.

    • support for things such as 8 bit colour modes
    I am actually far more confident that Flash could be used to simulate 8 bit colour games, with realtime palette effects and everything, than HTML5. Surprisingly enough.
    QuoteAlso, ! probably is not the best simple conversion candidate due to the unconventional nature of it. Have you tried working with multiple mouse modes and inventory items?
    This is true, and no, I have not. Even more significantly, it doesn't even have walk zones. Walk zones! How do you live without them?
    Quote
    Once again most impressive work. If you'd like more source code to experiment with let me know and I'll happily send you some.
    Thank you, that would be great. I definitely would like to try a medium sized game with walk zones, mouse modes, inventory items, many rooms, etc.
    #93
    Inspired by this thread from last year, I have been working on a proof-of-concept demo for an AGS game running in a browser, a similar idea to clarvalon's XAGE running on .NET Silverlight, except that the primary language is the browser's own JavaScript, using HTML5 or Flash to handle the audio and graphics output.

    The demo is of Ben Chandler's awesome miniature-epic "!", for which he graciously released the source code last year.


    Any relatively recent version of Firefox, Opera, Chrome or Safari should be able to play this without requiring Flash. IE8 (and hopefully IE7 and maybe IE6, though I haven't been able to test) should be able to play it, but will require Flash 10+ plugin. You can also see it in Flash mode in other browsers if you like:


    The "engine" is very incomplete, in fact it just barely covers the functionality needed to play this one specific game, and I even cut some corners towards the end because I was getting impatient :P But not too much, and I am pretty confident it could be fleshed out into something that could run most any AGS game. The question is, of course, whether this is something people really want, particularly as it is much, much harder to "protect" your game's resources. Someone determined who knows what they're doing can easily download all the files, read the script code, etc.

    Feedback and discussion welcome!
    #94
    Thanks! The scripts_dump.txt output isn't anything related to Lua, by the way, it's just an arbitrary format for demonstrative purposes but doesn't really have any use as it is.
    #95
    Quote from: Monsieur OUXX on Thu 16/12/2010 13:14:06
    Quote from: Denzil Quixode on Tue 14/12/2010 17:06:46
    I happen to already have most of a parser done already. I would be happy to extract it from the project I was making it for and fix it up into a reusable middleware DLL.

    DO IT!  :D :D :D

    <3
    OK, I've started a project at http://spags.googlecode.com/ (SPAGS: Script Parser for AGS :P). If you can use SVN you should be able to get it. It includes a project for a test plugin SPAGSTest that creates a file called scripts_dump.txt in the game's project directory (select the SPAGS > Dump Scripts menu item) which isn't very useful on its own but hopefully demonstrates what the parser has understood. Also the source code for that plugin should hopefully be instructive for how to use SPAGS itself - though things might change a bit in the future, it's still very much a work in progress. Also currently it only handles global scripts, not yet room scripts or dialog scripts - but it should be able to handle any global script that would compile normally.

    When it's a bit more mature I'll make a thread about it in the technical forum, but I'm still tinkering with it for now.
    #96
    Hmm, I hadn't even heard of ANTLR before... interesting. Actually I happen to already have most of a hand-written C# parser done already, which creates an object-based representation of AGS Script. I would be happy to extract it from the project I was making it for and fix it up into a reusable middleware DLL that people can use in their own plugins. (I'd release it as open source, too, why not.) I need a few days though - my main laptop is in for repairs at the moment and that's got all my plugin stuff on it...
    #97
    Quote from: monkey_05_06
    Some of the AGS methods the plugin provides are a bit wonky to actually use, which I probably would have commented on if I were developing with it further.
    Like the way you have to use attributes as if they were methods? It actually would have been possible not to do that... but at the cost of potentially making performance a  bit worse, because of the internal magics needed. I'm not sure I made the right decision.

    Quote from: monkey_05_06
    Also, some of the Lua scripting is difficult to use and/or inconsistent with the way AGS handles things. For example, it's impossible in Lua to set the player's active inventory to nil (this crashes the game). Presumably this would be equivalent to setting player.ActiveInventory = null..and I couldn't think of any work-around for this scenario..short of just using AGScript.
    This sounds like an outright bug. It's something I simply forgot to try in my own testing,  I guess. I won't be able to sort it out until next week.

    Also, reeading your other comments about having to convert your module made me realise that maybe what would be really useful here would be a special splitscreen utility for the plugin where you can copy and paste AGS script into the left hand side,  click a "Convert" button and it will generate equivalent Lua code on the right hand side. I will look into that too.
    #98
    Quote from: Monsieur OUXX on Thu 09/12/2010 12:19:11
    Is it unrealistic to hope controlling AGS from the Lua script exactly the same way you'd control your game from the AGS script? Have you bound all AGS objects in your Lua plugin? (That is: Can I iterate through objects, characters, rooms...
    Can I read the game's parameters... Can I call AGS functions such as "Changeroom".. etc?)
    Yes, you can call standard built-in functions and methods, and refer to built-in objects like GUIs, inventory items, etc. The main thing you can't do is directly call your own AGS-script functions, or get/set your own AGS-script variables - there simply isn't any way to do that through the AGS plugin system, currently. You also can't directly control other plugins.

    See this page for more info about what you can do through the ags table: http://lua-for-ags.wikispaces.com/agsTable - there's a table that shows the Lua equivalent to things you do in AGS script.
    #99
    Okay, nobody is using the plugin then :P Oh well. Very sorry to hear about your HD woes, monkey - I've been there...
    #100
    Quote from: Monsieur OUXX on Wed 08/12/2010 19:06:36
    Has anyone started using the plugin seriously?
    (...)
    For short : how mature is the plugin?
    I am only aware of one person who has seriously tried to use the plugin, apart from me. I'd say it's therefore still very immature, because it does not have a big proof-of-concept game. (I was hoping to make one, but you know how it is...)

    QuoteIs it convenient to try controlling AGS from LUA (using that "ags" object DQ mentionned), or is the only working strategy to call LUA from AGS?
    It really depends how you want to use it, unfortunately (I think this is the big problem with the plugin, there is no definitive way to use it.)

    Quote(and by the way it must be slow every time AGS calls a LUA function?)
    Depends what you mean by slow. It's certainly slower than calling an AGS function but I think you should be able to make quite a lot of Lua calls every frame (assuming 40 fps) before it causes any slowdown.

    (Also, this is a very picky thing but:- unlike "AGS", "Lua" doesn't stand for anything, it's just a name, so it's more correct to call it "Lua" rather than "LUA".)
    SMF spam blocked by CleanTalk