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

Proposals / Re: Modifying the way we select objects
« on: August 03, 2014, 11:36:08 AM »
I'd make that when you double-click it in the list; could be annoying, otherwise (side-by-side instances can be far apart in the room, and you're more likely to care while editing instances).

Proposals / Re: Threading
« on: August 03, 2014, 11:25:12 AM »
Worry about them all you like. I doubt you would have much luck implementing either of those right now.

Programming Help / Re: image_angle & view_angle : problem !
« on: August 03, 2014, 10:55:21 AM »
Robert, the room view code uses d3d_set_projection_ortho itself. The skewing is a function of the aspect ratio. If the room were, say, 560×560 instead of 640×480, there wouldn't be a problem with the aspect. We could ostensibly fix this by applying the rotation to the projection width and height, but that shouldn't be necessary. If I had to guess, this is solved by applying the rotation after the scaling and before the translation when creating the matrix. Right now it seems to be specified first of all, so it's not surprising we're getting skewing issues. I'll need to sit down and think about it to get the right order for the transformations. My intuitive best guess did not cut it.

Proposals / Re: Threading
« on: August 02, 2014, 08:05:11 PM »
I don't like the idea of a new syntax for threads. The new parser supports anonymous functions. If it doesn't, it will briefly.

Code: (EDL) [Select]
function my_thread() {
  for (int i = 0; i < 10; ++i) {
    show_message("Thread Running");
  show_message("Thread Done");

var thread = thread_function(my_thread);

Basically, leave the syntax modifications to supporting dynamic functions in general. A thread_start, thread_join, and thread_signal will follow from there.

Developing ENIGMA / Re: Font Pixel Alignment
« on: August 02, 2014, 10:55:38 AM »
The text is faint where pixels from a 1px-wide vertical portion are drawn horizontally across two pixels, and likewise where pixels from 1px-thick horizontal portion are drawn across two pixels vertically. This happens when the pixels are not contained in integer bounds—i.e, when the center of the pixel is drawn anywhere but a half-pixel boundary. From what I'm seeing, this happens every other glyph, meaning that at some point, they *are* aligned, and at some point, they aren't. Considering it alternates, the only logical conclusion is that someone is adding floating point numbers to the font spacing accumulator, which I told Robert would require rounding before drawing at those coordinates. It seems he's figured that much out.

Setting the projection to half-pixel coordinates should be the default behavior for draw_/d3d_set_projection_ortho. This isn't just for fonts; it's for every single sprite-based resource. With interpolated lines, it'll also be clear really quick that the projection is not half-pixel aligned.

Again, fonts should be drawn at whole-integer bounds. The projection should be set with a half-integer shift. That's just how 2D game projections work.

Hm. It's possible there's some default code in events.res that is creating problems. I might ask Sorlok; he's the one who implemented timelines for us, so he'll recognize that code.

Could you tell me what happens if you disable the Timelines extension? If it's disabled, enable it, and the problem should go away.

Programming Help / Re: image_angle & view_angle : problem !
« on: August 02, 2014, 10:44:56 AM »
It seems ENIGMA is mishandling the view_angle transformation. I'm merging something in from Robert now, and I have a small laundry list of other things to check in with it. I'll see if I can't reproduce your problem and fix it.

Proposals / Re: Flipping, scaling and rotating instances
« on: August 02, 2014, 10:35:45 AM »
That is exactly what I was going to have him do, Harri. There's no point in adding arbitrary numbers of variables to our list format when 99% of objects won't use all of them, and more than half of objects won't use any of them. Just prefix it to the creation code. This allows injecting arbitrary variable assignments. Plus, the code is executed inside the frame of the instance in question. There's no reason not to do it this way.

Programming Help / Re: image_angle & view_angle : problem !
« on: August 02, 2014, 10:18:41 AM »
The grid you are seeing is caused by gaps in the tiled background. The graphics card should not be doing that; those polygons share coordinates, so even if the pixels didn't belong to one tile, they should belong to the next...

The skewing you see instead of rotation, however, is entirely our fault. I'll look into why that's happening.

Does the third screenshot show us what happens in GM8 when you press left? I.e, does the sprite rotate to remain upright while the world rotates around it?

Off-Topic / Re: NakedPaulToast
« on: August 02, 2014, 09:46:07 AM »
I hope you'll point out if I ever do that. :P

Developing ENIGMA / Re: Font Pixel Alignment
« on: August 01, 2014, 07:02:48 AM »
No. The purpose of padding is to prevent noise around glyph bounding rectangle edges from nearby glyphs being interpolated across those boundaries. This is due to the fact that every time someone tries to half-pixel align ENIGMA's orthographic projections, as they should be, there's a 16-week debate about how this actually makes some cards rendering worse. Of course, in this case, it doesn't seem to matter. Every other glyph is drawn correctly, which means to me that someone is adding half-pixels to the font coordinates and not rounding them before drawing.

Proposals / Re: Close file without closing LGM/ENIGMA
« on: August 01, 2014, 06:58:38 AM »
If a second project opens in LateralGM without closing the first, that's a bug. A bad bug. If you hit save, you WILL save the contents of both games to the newly opened project if that really happened. And you will have duplicate IDs, and your game will be very hard to salvage.

The new button is the only way we have of "closing" a project, because it does not support loading two projects. Are you able to get it to load one project over another? Could you screencap it and/or file a bug?

As long as he has installed ENIGMA somewhere in his home folder, he does not need sudo. Windows is the only platform on which ENIGMA needs elevated privileges to function.

It's sounding like multiple games are working fine for you. What problem are you having right now, and how can someone reproduce it?

Developing ENIGMA / Re: Graphics system compatiblity
« on: July 31, 2014, 08:20:15 PM »
> I like the E_ANNO idea, and I can put anything in it, not only "Graphics system specific", but maybe even on how to replicate the functionality in other systems?
Try to be consistent, but yes.

> Then it will get bloated though. But if I got you correctly, then JDI would use this to throw errors?
Correct. I will have to modify JDI to support these annotations, but that has already been on my radar. I expect to get a lot of use out of that ability.

> And you said I have to do this in headers - so I put all platform specific functions in their own headers inside the graphics systems folder and do it there?
In this case, yes. These annotations don't typically belong in shared headers unless the headers are to be shared between small numbers of systems which both implement non-uniform functionality. This should be unlikely.

> So that the function doesn't even appear in the code editor unless the correct graphics system is enabled?
> Because right now many system specific functions are in General, and they just have empty implementations. I guess I will have to clean that up.

Right. I'm generally opposed to empty function bodies; I really hate linker errors, though. I'd prefer they just not be declared in systems that don't do anything for them, unless they're still applicable for a system. For instance, it's OK if d3d_enable didn't do anything on some embedded system, as long as you could do everything you'd be able to do after calling that function.

Off-Topic / Re: MacOS Counter-intuitive?
« on: July 30, 2014, 10:31:48 PM »
It comes down to a matter of philosophy. What could be simpler than one giant button?

This philosophy continues to be a big part of Apple's R&D:

You shouldn't be mad at them for running off with BSD, though; BSD devs aren't. They do give back, as needed. They just don't help with, eg, X11's huge set of ancient problems. In fact, they've ruined X11 on OS X. Rather than write wrappers for it and GTK (assuming that'd even be needed if they offered a full X11 API), they've decided to just write a shitty window adapter, which has to be run as a separate process any time you want to open anything GTK.

From a structure standpoint, OS X is vastly superior to Windows. For example, creating a button is not a kernel operation in OS X. From a usability standpoint... well, Snow Leopard is an improvement over Leopard which is a MASSIVE improvement over Tiger, which made my unfortunate existence a living hell with its astounding unintuitiveness and general brokenness. Of course, I was the tech guy, so all of everyone's problems were my problems and so I am likely to hold some kind of bias. As someone who is particularly picky about my windowing environment, I also find Tiger's window manager to be worthless, featureless garbage. Leopard vastly improved on that, but the whole system still leaves a lot to be desired. I'd put Snow Leopard < Windows 7 < Unity < Every other Linux DE < GNOME 3 < Cinnamon < XFCE < GNOME 2 (Note that in general XFCE is the best due to its extreme customizability, but I really loved the features available in a default GNOME 2 install).