tulamide's Forum Posts

  • Hope this will help you :)

    mirrorbeams.cap

  • Sure, I'll do my best :)

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I might misunderstand something here, but from what you posted from your events, it is normal behavior.

    You are setting the global 'BookCount' to the value of the private 'BookCount' of Text_BooksIndicator at every tick.

    So whatever you add to the global in the collision event, the value will be replaced by the value of the private variable right afterwards. It will keep its value for just one tick (which you won't notice)

    Example

    Text_BooksIndicator('BookCount') = 0

    global('BookCount') = 0

    Tick 120

    Collision event, global set to 1

    Tick 121

    global set to Text_BooksIndicator('BookCount') = 0

  • I'm not debating on principles, I'm just giving a hint to those who wonder, why Flash isn't dying as fast as they thought.

    You can either accept the facts, or ignore them. I didn't say anything against the future of HTML5, I rather said, that it will have success. I'm talking about the current situation as a hint to why Flash is in the lead right now.

    And why do you accuse me for showing sources? I even didn't use the higher ones (some see over 55% of XP). But at least I showed them. For example, Ashley stated that over 50% of the browsers are Firefox and Chrome, but he did not provide any source.

    The W3Schools' stats aren't saying much. They were collected only from the users of that site:

    <font size="2">"W3Schools is a website for people with an interest for web technologies. These people are more interested in using alternative browsers than the average user. The average user tends to the browser that comes preinstalled with their computer, and do not seek out other browser alternatives.

    These facts indicate that the browser figures above are not 100% realistic. Other web sites have statistics showing that Internet Explorer is a more popular browser.

    Anyway, our data, collected from W3Schools' log-files, over many years, clearly shows the long and medium-term trends."</font>

    The W3counter link is a better one, having a lot of different sites in surveillance. And it shows the same, what I pointed to: A high user base with WinXP.

    Statcounter again shows that large WinXP user base. It is a difference, if you use IE with Win7 (IE9+) or WinXP (IE8-). And it is a difference, if one uses Firefox with Win7 (hardware-acceleration support) or with WinXP (no support).

    So, thanks for those links, they confirm that there is still a large user base that has no hardware-acceleration support and therefore will prefer Flash.

    Again: it is the current situation. It has nothing to do with the future or the quality of HTML5 or C2 or Ashley's hard work to establish a really good game maker for that market! It is just the answer to those who wonder, why Flash is still so popular. As I said in a previous post: It will slowly change over time. It is not a matter of "if", but "when".

  • Where are you getting your figures for "a minority" from?From the sources I provided. If you follow the links, you can see them for yourself :)

    Over 50% of the web is Firefox or Chrome which both support WebGL with fallback to hardware-accelerated 2D canvases.That are two points, that are not quite correct. Firefox and Chrome make 41%, while Explorer makes 52%. And you forgot again to see the fact, that 47% of the computers still use WinXP (Vista and 7 combined make less, 45%, Win 7 alone only 37%), so no hardware support for those, if they are using Firefox or IE. Chrome just makes 19% overall, and we know that those 19% are NOT only using WinXP, but Win 7, too. Let's say, it's half of them (I doubt it). That would still be around 39% of users who don't have hardware acceleration support.

    source

    Of IE, 10% is now IE9 with hardware-accelerated 2D canvas. Obviously IE8 and earlier aren't supported, but the browsers which don't have hardware-accelerated HTML5 gaming are now in the minority!See above. While it's true that Firefox and IE do support hardware acceleration, it isn't available for those, who still use WinXP, which is at least 39% of all web users. That's what I meant with "underestimated".

    There's nothing, one could do about it. As time goes by, the huge base of 47% WinXP as operating system will shrink. But I'm absolutely sure, that's one reason for HTML5 not becoming as fast the successor to Flash as was hoped.

  • When everyone says that Flash dies and it's Html5 days,

    what I can see is Flash ads/games still everywhere and Html5 is struggling with cross-browser problems(eg. audio/video), furthermore, big Html5 game company shutdown.

    http://www.insidemobileapps.com/2012/01/09/moblyngs-shutdown-enthusiasm-for-html5-gaming-is-still-a-little-premature/

    There's a point here, that I think is totally underestimated. People don't care about the technology or the platform, they just want to play. And when they play, they prefer to have a good gaming experience. I know that sounds so obvious, but here are some facts.

    1) 47% of all desktop computers use Windows XP as operating system

    source

    2) The leading web browser versions are Internet Explorer 8 with 28% and Firefox 8 with 12%

    source

    So, there's only a minority that makes use of hardware-accelerated HTML5 canvas. 28% can't play at all, and for the rest it is terribly slow (<10fps).

    On the other hand there's Flash. Constant 30 fps even on an older cpu (and with IE8).

    As long as those numbers don't change significantly, I wouldn't hesitate to predict, who's winning. And even Ashley can't do magic. If HTML5 isn't hardware-accelerated on the majority of browser/operating system combinations, it is too slow compared to Flash, to have any success for now. It will change slowly over time, when more and more people will go from XP to 7, but that's a process that will endure a few years.

  • Does that mean that any "On trigger" condition are effectively placed at the top of the event sheet, since you said their location doesn't matter in the event sheet?

    It means that it isn't any more effective than placing them at the end of the event sheet, or somewhere in between. It simply doesn't matter. They will be executed as soon as the trigger is true. (just like "Start of layout" gets executed before anything else, even if you place it at the end of an embedded event sheet, that you embed at the end of your actual event sheet)

  • <img src="http://icanhascheezburger.files.wordpress.com/2011/01/funny-pictures-gif-cat-stand-squat.gif" border="0" />

    Oh my gosh, Garfield lives! <img src="smileys/smiley4.gif" border="0" align="middle" />

  • So using this, it would be possible for a player to select a resolution from this list, and the game update its display to reflect that decision?

    It is possible to develop exactly that, yes. But the provided script just does the first, most important step for you: It lists resolutions that you can be sure of to be supported as fullscreen modes. All you have to do is this:

    1) Offer the player the list to choose one of the resolutions.

    2) Set the window to this resolution.

    3) Switch fullscreen on.

    Of course, you still have to decide what to do with the layout (stretching, black bars, zooming, etc.)

    But without that list, you couldn't offer different fullscreen modes at all (apart from the current desktop resolution). So, the most important part is ready to go, but you still have to program all the details.

  • The solution to that was to cache the music files before the level loads, but it poses its own problem. Yes, I can load them in a "loading" layout beforehand, but there's no way to tell when it is finished!<font size="2">Well, there is a way to tell ;)

    Caching is done within one tick. There is no way to stop the process.

    + System: Start of layout

    -> XAudio2: Cache file AppPath & "music\first.ogg"

    -> XAudio2: Cache file AppPath & "music\second.ogg"

    -> System: Go to layout 2 with transition "None" lasting 0 MS

    This will switch to layout 2 as soon as the two files are cached. It will not go the specified layout before both files are fully loaded to memory.

    + System: TickCount Equal to 60

    -> XAudio2: Cache file AppPath & "music\first.ogg"

    -> XAudio2: Cache file AppPath & "music\second.ogg"

    + System: TickCount Equal to 61

    -> System: Go to layout 2 with transition "None" lasting 0 MS

    This will switch to layout 2 right after the files are cached, at tick 61.

    You could also start with doing all the loading of other stuff, then when you're ready to cache the ogg files, store the current tick count to a variable and go to another layout as soon as the caching is done:

    + System: Timer is Equal to 1000

    -> XAudio2: Cache file AppPath & "music\first.ogg"

    -> XAudio2: Cache file AppPath & "music\second.ogg"

    -> System: Set global variable 'cachingTick' to TickCount

    + System: Is global variable 'cachingTick' Greater than 0

    + System: TickCount Equal to global('cachingTick') + 1

    -> System: Go to layout 2 with transition "None" lasting 0 MS

    </font>

  • But if V-Sync works that way, shouldn't the lag theoretically get worse each second then? Like I wrote in my example with the counting of the second?

    In other words, reading of the code is not affected by it.

    That's not true. Code execution and rendering are synchronized. While the graphic card renders the actual frame, the code executes the events for the next frame - and then waits until the graphic card is ready for the next rendering. When talking of buffering on the software site, we are talking of single or double buffering at most.

    If you experience significantly lag, it might be another issue. Today's graphic cards do also buffer frames (they do it to let movement appear smoother when the frame rate is low). For example, NVIDIA cards are set to buffer at least 3 frames by default. You could check if setting such a card's buffer to a lower value helps.

  • Germany was trying to censorship a few times. The government seriously thought about prohibiting Facebook parties, locking sites (centralized DNS blocking) and more. Until today, we (the people) were able to prevent this.

    However, there is another power, and this one is effectively censoring in germany, right now. It is a collecting society called GEMA. This is what it looks like, if you try to watch videos on youtube, when GEMA thinks, youtube hasn't paid enough money (just took two examples from the us top-40 charts):

    http://dl.dropbox.com/u/11182740/pictures/youtube01.jpg

    http://dl.dropbox.com/u/11182740/pictures/youtube02.jpg

    GEMA acts on their own, even the labels are fighting against it. It's a shame that money can do, what people prevented from their government.

    But back to topic.

    SOPA would be a huge step. Besides a censorship on the us citizen side, it is giving the us access to foreign corporates and sites. And worst of all - it will be a signal to all other countries, like the ones in europe, to also establish something like it.

    Stop this!

  • I'm not much into it, but I found this to be an interesting aspect (sporadic funny subtitles included^^):

    Subscribe to Construct videos now
  • Groups are used to organize code sections within an event sheet, includes are used to reduce the amount of events needed for a project.

    Includes are reusable event sheets, they exist only one time while used in several other event sheets. This reduces the file size on disk as well as it reduces the effort needed, when you have to change or correct something in those sheets. You only need to do it once, it is then corrected for all sheets, where those changed ones are included.

    Example

    You have three layouts, and the player's sprite is always controlled the same way on all of them.

    Organized in groups it will look like:

    Layout 1

    -group player control

    --event

    --event

    --event

    -other events

    Layout 2

    -group player control

    --event

    --event

    --event

    -other events

    Layout 3

    -group player control

    --event

    --event

    --event

    -other events

    Organized with includes it will look like:

    sheet player control

    -event

    -event

    -event

    Layout 1

    -reference to player control sheet

    -other events

    Layout 2

    -reference to player control sheet

    -other events

    Layout 3

    -reference to player control sheet

    -other events

    Now you need to change an event of the player control.

    Working with groups:

    Layout 1

    -group player control

    --event

    --event <- You change this event

    --event

    -other events

    Layout 2

    -group player control

    --event

    --event <- You change this event

    --event

    -other events

    Layout 3

    -group player control

    --event

    --event <- You change this event

    --event

    -other events

    Working with includes:

    sheet player control

    -event

    -event <- You change this event

    -event

    Obviously there's an advantage over groups. In short:

    -Whenever there is a set of events that will be used in more than one layout the same way, use a seperate event sheet and include it.

    -Whenever you need more overview, or have alternating sets of events that may be switched, within an event sheet, use groups.

  • Yes, it is an issue. One thing you have to do is using the family manager for adding private variables to a family - and even then there are odd behaviors sometimes.

    So, never add a pv to an object and then add it to a family. Instead, add it to the family, and if this pv already exists for the other objects in the family, it will ask you if it should add the pv for that object automatically. The cleanest way would be to have all the objects for the family without any private variables, then add them to the family and then add the pv using the family manager.

    Or, just try as newt said :)