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.


Messages - Josh @ Dreamland

1651
General ENIGMA / Re: Marketing Enigma
« on: October 19, 2010, 05:41:20 PM »
- How are main stream Game Maker users going to hear about Enigma?
Eventually, I'll create signature banners for people to use on the GMC. Most of ENIGMA's users are intelligent enough to be giving frequent help on the GMC. If each of them has ENIGMA in their banner with an enticing message (see next answer), we are bound to start drawing in new users.
- What information is best displayed to GM users in order to entice them into using Enigma?
The first phrase in every ad will be about how ENIGMA is free. ENIGMA's strength is in extensibility and speed, but compared to GM, It is parsecs ahead in security, as far as the unlikelihood that games will be decompiled. It seems at this point that ENIGMA will offer an improved size compared to GM games. Also, we're leagues ahead of GM in the race for cross-platformability. Users who wish to display ENIGMA's banner in their signature can choose their favorites to brag on.
- Do you expect there will be any backlash from YYGs in the future over the development of Enigma?
They might try. We're not concerned; they have no legal ground to tell us to stop, as no copyrightable material is used from GM in ENIGMA. (A language cannot be copyrighted, and we don't distribute anything they own).

- How are users of other game development software going to hear about Enigma?
I don't intend to subtly invade other projects' sites. If other projects' users are discontent with pricing or speed of that project, they may happen upon ENIGMA in the same way they happened along GM, or whatever.
- What information is best displayed to these people?
Again, start with how ENIGMA is free. From there, we'll make mention of the fact that ENIGMA uses C++, and is easily re-compiled for a different platform. We'll also make clear that ENIGMA offers a number of easy-to-use, unified resources.

- How in general are people going to hear about Enigma?
Largely word of mouth. (As in, on message boards or in blogs related to game design). Only after ENIGMA catches on that way will search engines point our way.
- How common will it be for people to stumble across Enimga using Google?
As I mentioned earlier, not very, until ENIGMA gains popularity by other means. That's just how search engines work.
- What information should be displayed to these people?
Same as to those coming from other projects.

- Is it likely members of this community will take it upon themselves to advertise/mass spam Enigma?
Spam implying unwelcome messages with the sole purpose of advertising ENIGMA, I don't encourage it, but it may happen. I'm not opposed to using signature banners as a small-scale Goo
BOT
gle b
CRAWLER
omb, though.
- Is this a concern for you?
I'm not worried about it, especially if I'm offering signature banners (which are a subtle but effective alternative). I will probably post a message discouraging it so as not to be held accountable.
- At what stage in Enigma's development should marketing be considered? (Advertising before Enigma is reliable/useful enough can obviously have negative effects)
When the collision system is done, I have all functions of std::map working in ENIGMA, and I have all local groups (such as path_ variables) managed by a set of YAML files that allow local-based resources to be added without modifying the compiler. At that point, ENIGMA will have more than enough functionality to make a decent game, and the rest of the the functions and resources will be trivial.

- How fast do you think the community will grow?
Slowly at first, but faster with time.
- How popular will Enigma ultimately become?
I can't say. I know ENIGMA has great potential, but that often isn't enough.
- What kind of users will end up here?
I Don't think there's a particular kind of user that will be attracted to ENIGMA. If you're getting at the average IQ of GM users, then yes, we have some of those.
- How many users do you expect will be willing to work on Enigma's development?
Right now we have more than I expected. At this rate, we'll have at least a dozen people with notable contributions.
- How is the forum/website/development going to change in order to cater for an increase in it's user base?
In my wildest dreams, sure. As ENIGMA starts to gain popularity, we will move the ads to the forum pages like Yoyo did. Those will, I hope, generate more revenue from the increased traffic, some by accident, some by people who aren't sure if they want to go with ENIGMA or just any old game development toolkit from the ads. As we gain more revenue, we can move to a larger host, and start game hosting like Yoyo does. The more we grow, the more stuff we can do that Yoyo does now (Higher capacity hosting, competitions for small cash amounts, etc). At this phase, all of that is completely impossible; the ads on the front of this site barely generate enough revenue to cover this site's current host. But, if all goes this well, we can grow.
- At what point do you need to start actually thinking about all these things?
I've been thinking about most of these all along, but they are quickly becoming necessary to consider.

1652
General ENIGMA / Re: TGMG - A word...
« on: October 19, 2010, 03:18:43 PM »
Which is the only way to consistently pull of the code I posted above. Otherwise, the b could be misaligned with the a for everyone not using a tab width of 2, or whatever.

1653
General ENIGMA / Re: TGMG - A word...
« on: October 19, 2010, 12:18:26 PM »
...okay.


:P

1654
General ENIGMA / Re: Android support
« on: October 19, 2010, 09:31:32 AM »
Yes. In the beginning, when the earth was young and ENIGMA was just an idea entering the planning phase, Dave asked me why I would bother keeping GML. I told him it could attract some of the GM crowd, of course, but that having a wrapper to everything would mean that we could switch out the API without changing any of the high-level code. Three years later, that's a reality.

Right now, only Apple can compile for Android, because that's what TGMG was writing it on. But I imagine he can make it work for Windows. I'll not volunteer him for the job, though.

1655
General ENIGMA / Re: TGMG - A word...
« on: October 19, 2010, 09:11:41 AM »
I like consistency, and tabs don't offer that. Wherever I open my code, I want it to look the same.
Code: (C) [Select]
{
  float a = 0,
        b = 1;
I don't like going out of my way to make it [tab]float...[tab][space][space][space][space][space]b...
I like pressing tab two or three times, then just backspacing to where it lines up.

I also like leaving indentation on blank lines. That way, I just click where I want to insert, and press enter. But no, damn IDEs keep stripping trailing blanks.

Anyway, iirc tabs are illegal in YAML, Firefox strips them from non-first-char pastes, replacing them with spaces.... they're a dying breed.

1656
Off-Topic / Re: Hey guys, thanx.
« on: October 18, 2010, 07:28:09 AM »
I'm not going to volunteer at this point, but it seems more than likely that if U3D is so popular, someone will implement it as part of ENIGMA's official API. So I don't at all oppose its use if you feel strongly about it.

1657
Announcements / Re: What's happening now
« on: October 17, 2010, 12:44:24 PM »
We may need to set up our own repository. I doubt ENIGMA will just waltz into the main Ubuntu repo (But never say never. I intend to try).

1658
Good point. Maybe I'll drop him a letter later.

1659
Off-Topic / Re: Hey guys, thanx.
« on: October 17, 2010, 12:42:40 PM »
Our d3d_ functions probably won't suck. r9k implemented some of those sometime last Thursday.

1660
Well, that's a mistake in itself. You could have the most outstandingly efficient piece of GML fathomable, and on the optimization scale, it'd be a steaming pile of shit and rusted bolts compared to the equivalent in a real language. Not just because GM's interpreter is slow, but because GM's pointerless, classless system makes you do all sorts of running around to get something simple done. Compare a C Brainfuck interpreter to a JavaScript one. There's no comparison.

But yes, your purpose is legal, then; as Ism said, it's just common courtesy to let him know we're using them. (Even though I don't find anything particularly insightful about his code, it's the idea that counts). But, seeing as that site is full of people taking such scripts and running with them without credit, I suppose it'd only be annoying if everyone that found use for them emailed him. So do what you like.

Anyway, yes, I'm a proponent of integral coordinates. Except one thing:
All vars are double. To call your function, they are cast as int.
You then invoke glTexCoord2f, casting them back to float.

I do the same thing; I've been waiting for someone to help me decide what to do about it. I think at this point swapping them all for 2i would be our best bet.

1661
Announcements / Re: What's happening now
« on: October 17, 2010, 08:18:25 AM »
We're working on that. By which I mean, I'm hinting to Ism every week or so that I hate it when that thing covers my game window.

1662
Function Peer Review / Re: GML: draw_sprite_tiled + draw_sprite_tiled_ext
« on: October 17, 2010, 08:15:30 AM »
What am I never minding?

1663
Function Peer Review / Re: GML: draw_sprite_tiled + draw_sprite_tiled_ext
« on: October 16, 2010, 09:55:24 PM »
Oh, don't worry about that. I replaced your use of room_width and height with a simple ternary expression. Views are inefficient as dog in GM anyway.

This is the code I ended up including, which I will assume to work until further notice:

Code: [Select]
int draw_sprite_tiled(int spr,int subimg,double x,double y)
{
  enigma::sprite *spr2d = enigma::spritestructarray[spr];
  if (!spr2d)
    return -1;
 
  if (enigma::cur_bou_tha_noo_sho_eve_cha_eve != spr2d->texturearray[subimg % spr2d->subcount])
  {
    glBindTexture(GL_TEXTURE_2D,spr2d->texturearray[subimg % spr2d->subcount]);
    enigma::cur_bou_tha_noo_sho_eve_cha_eve = spr2d->texturearray[subimg % spr2d->subcount];
  }
 
  glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_CLAMP);
  glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_CLAMP);
 
  glPushAttrib(GL_CURRENT_BIT);
    glColor4f(1,1,1,1);
   
    const float
      tbx  = spr2d->texbordx,  tby  = spr2d->texbordy,
      xoff = spr2d->xoffset+x, yoff = spr2d->yoffset+y;
    const int
      hortil = int (ceil(   (view_enabled ? view_xview[view_current] + view_wview[view_current] : room_width)    / (spr2d->width*tbx))),
      vertil = int (ceil(   (view_enabled ? view_yview[view_current] + view_hview[view_current] : room_height)   / (spr2d->height*tby)));
   
    glBegin(GL_QUADS);
    for (int i=0; i<hortil; i++)
    {
      for (int c=0; c<vertil; c++)
      {
        glTexCoord2f(0,0);
          glVertex2f(i*spr2d->width-xoff,c*spr2d->height-yoff);
        glTexCoord2f(tbx,0);
          glVertex2f((i+1)*spr2d->width-xoff,c*spr2d->height-yoff);
        glTexCoord2f(tbx,tby);
          glVertex2f((i+1)*spr2d->width-xoff,(c+1)*spr2d->height-yoff);
        glTexCoord2f(0,tby);
          glVertex2f(i*spr2d->width-xoff,(c+1)*spr2d->height-yoff);
      }
    }
    glEnd();
  glPopAttrib();
  return 0;
}

int draw_sprite_tiled_ext(int spr,int subimg,double x,double y, double xscale,double yscale,int color,double alpha)
{
  enigma::sprite *spr2d = enigma::spritestructarray[spr];
  if (!spr2d)
    return -1;

  if (enigma::cur_bou_tha_noo_sho_eve_cha_eve != spr2d->texturearray[subimg % spr2d->subcount])
  {
    glBindTexture(GL_TEXTURE_2D,spr2d->texturearray[subimg % spr2d->subcount]);
    enigma::cur_bou_tha_noo_sho_eve_cha_eve = spr2d->texturearray[subimg % spr2d->subcount];
  }

  glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_CLAMP);
  glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_CLAMP);


  glPushAttrib(GL_CURRENT_BIT);
  glColor4ub(__GETR(color),__GETG(color),__GETB(color),char(alpha*255));

    const float
      tbx  = spr2d->texbordx,         tby  = spr2d->texbordy,
      xoff = spr2d->xoffset*xscale+x, yoff = spr2d->yoffset*yscale+y;
    const int
      hortil= int (ceil(   (view_enabled ? view_xview[view_current] + view_wview[view_current] : room_width)    / (spr2d->width*tbx*xscale))),
      vertil= int (ceil(   (view_enabled ? view_yview[view_current] + view_hview[view_current] : room_height)   / (spr2d->height*tby*yscale)));
   
    glBegin(GL_QUADS);
    for (int i=0; i<hortil; i++)
    {
      for (int c=0; c<vertil; c++)
      {
        glTexCoord2f(0,0);
          glVertex2f(i*spr2d->width*xscale-xoff,c*spr2d->height*yscale-yoff);
        glTexCoord2f(tbx,0);
          glVertex2f((i+1)*spr2d->width*xscale-xoff,c*spr2d->height*yscale-yoff);
        glTexCoord2f(tbx,tby);
          glVertex2f((i+1)*spr2d->width*xscale-xoff,(c+1)*spr2d->height*yscale-yoff);
        glTexCoord2f(0,tby);
          glVertex2f(i*spr2d->width*xscale-xoff,(c+1)*spr2d->height*yscale-yoff);
      }
    }
    glEnd();

    glPopAttrib();
    return 0;
}

I have one bone left to pick with it, being that it does not account for a special-case optimization in which the bind mode can be set to GL_WRAP and the sprite can just be drawn large. This can be checked for simply by testing that both spr->texbordx and texbordy are 1. In this case, the entirety of the allocated space is used, and there is no need to loop anything (The GPU is, of course, much more proficient at menial looping than the CPU).

My recommendation, as I will soon implement if no one else does, is a pattern like so:

if (spr->texbordx == 1)
{
  if (spr->texbordy == 1)
  {
     Draw single quad with appropriate texture bounds. Negative and extremely large bounds are both valid.
  }
  else
    for (all Y coordinates)
     draw a large horizontal quad with appropriate x bounds, but with texbordy as the y bound.
}
else
  if (spr->texbordy == 1)
    for (all X coordinates)
     draw a large horizontal quad with appropriate Y bounds, but with texbordy as the Y bound.
  else
   Exactly what you do now.

Granted, that's a "fucking large function," and with two branches, no less. The average time saving becomes a question, and we have to wonder if it was worth it for the extra checks and the extra memory. (Both of which are relatively negligible; it's all a matter of weight).



And this is the shit I mull over all day and night.

1664
Off-Topic / Re: Hey guys, thanx.
« on: October 16, 2010, 09:16:41 PM »
You know, DLLs are somewhat prototyped already. They should work, but I hear they don't, and simply haven't had the time (read, "patience for Windows") to look into the matter. And yes, HaRRi, you hit the nail on the head with the surface issue. But since Ism is working on YAML, we should stop running into compatibility issues altogether, as now we can fork a DirectX port that can be switched in and out at the push of a button (That's my number one logical defense for keeping GML).

I happen to be working on fonts as we speak, and Ism randomly took a liking to the issue and did the backend, so I can integrate her work as soon as I have a good rectangle packing algorithm.

1665
Function Peer Review / Re: GML: draw_sprite_tiled + draw_sprite_tiled_ext
« on: October 16, 2010, 01:55:48 PM »
Your choice to use room_width and height disregards views. Other than that, I guess I don't find fault with this.
I should also mention that I appreciate your single use of GL_QUADS, as opposed to one each for() iteration.