If you want something that only works for single player there are already ways to create things that look 3D (example). Being able to apply any projective transformation lets you create other types of effects, but if you're looking to create a single player game using these kinds of effects there are more practical platforms you can use.
I enjoyed Doom thoroughly.

Of course 3D is possible now. Kunark and others had several 3D demos a while back as sort of a showcasing that still weren't feasible for multiplayer games. For the kind of operations utilized in more of the fast-moving 3D, it'd be a lot quicker to have a way to apply multiple transformations at once without the overhead of every single DM call you make in the process building up on you.
In response to Forum_account
Forum_account wrote:
D4RK3 54B3R mentioned in passing that if he had access to a transformation matrix then he'd be jumping all over that for some pretty cool 3D effects.

I'm not sure how you'd create 3D effects with this. The transformation is specific to the atom - the same transformation is applied to the atom by all clients. For a 3D display you'd need to ability to represent objects differently to different clients.

That's pretty much exactly what I meant. Depending on the game and number of players (if it is indeed a multiplayer game), it may be necessary to make use of Gakumerasara's style of networking in Vengeance 56.

And again, you're right that there are other, more-practical platforms that are better if you're seeking to create a game with pretty effects.
I support this as well.
Relevant question: Assuming sprite mode gives us access to transformation matrices in DirectX, how would this be feasible in software rendering mode?
GDI+ (just a wrapper around our software GDI) can handle transformations, although I'm not sure how fast it is. I've been looking into this request as I do think it's very do-able without adding much complexity. Of course, like maptext, it adds more complexity to the impending flash client.
Being fast in hardware mode and slow in software mode is still much better than not having this feature.
I'm under the assumption if you're using software mode you're doing it wrong and probably shouldn't be playing in the first place. I would much rather have a more advanced hardware mode and no software mode rather than what we have now.
The problem is, SAx, that using any sort of transparency with the interface, you're stuck with software mode.
In response to Hiro the Dragon King
Hiro the Dragon King wrote:
The problem is, SAx, that using any sort of transparency with the interface, you're stuck with software mode.

Transparent windows aren't necessary. If you can make a decent game with transparent windows, it'd be a decent game without them.

SuperAntx wrote:
I'm under the assumption if you're using software mode you're doing it wrong and probably shouldn't be playing in the first place. I would much rather have a more advanced hardware mode and no software mode rather than what we have now.

I vaguely remember being told (by Tom or Lummox JR) that the flash client wouldn't hold back Dream Seeker - they wouldn't deny DS a feature just because it was hard to add to the flash client. I can't find the post where they said this, so I may just be imagining it.

Graphics really hold BYOND games back. A game's visuals are more than just the product of how well each icon is drawn. For the longest time it wasn't possible to run above 10 frames per second (I can't think of any decent game that has graphics and runs at 10 fps). That's fixed now, icons can move and animate smoothly, but there's still not much you can do with them. Being able to have GPU-handled transformation, coloration, and changes to opacity would almost make it possible to create a game that's pleasing to the eye.

Also, I'm still skeptical about how graphics are handled. Improved graphics (higher framerate, more objects on the screen, etc.) seems to greatly increase CPU usage. Since graphics should be handled entirely by the GPU, CPU usage shouldn't be a problem. Since it often is, it seems like the CPU is doing things it shouldn't.
In response to Forum_account
Forum_account wrote:
Also, I'm still skeptical about how graphics are handled. Improved graphics (higher framerate, more objects on the screen, etc.) seems to greatly increase CPU usage. Since graphics should be handled entirely by the GPU, CPU usage shouldn't be a problem. Since it often is, it seems like the CPU is doing things it shouldn't.

When you have a lot more graphics on the screen, you have a lot more objects/overlays/etc and that means more server processing and more client-updates. You can confirm this by testing in text-mode or by disabling drawing. If you have a counter example of a game that runs fine without graphics but has issues with graphics at a realistic (for BYOND) framerate (say 50fps or below), then I'd say there could be an issue with the drawing. I'd be pretty shocked though since sprite drawing is very straightforward in our system. It would of course get a bit more complex with transformations, but I don't expect that to be a problem in hw mode (not so sure about the GDI+ or Flash).
In response to Forum_account
Forum_account wrote:
Transparent windows aren't necessary. If you can make a decent game with transparent windows, it'd be a decent game without them.

I didn't say that they were necessary, did I? SAx was under the assumption that a player in software mode was doing it wrong and I provided a case where the player is forced to use software mode. On the developer side, no, they are not necessary, but nonetheless, I have played several games and demos that have used them, and I have used them myself occasionally.
If you're forcing people to use software mode just so you can have transparent windows, you probably are doing something wrong.

Also, it wouldn't be entirely inconsistent to simply not have this feature in software mode (or in the flash client, though that's probably more easy to do). I don't expect you'll be able to show this rotation in text mode displays (just like how you can't represent many other graphical effects in text mode).
That statement is rather vacuous. If the developer wants to do use window transparency, that is his choice. He is not doing something wrong. Some games can run perfectly fine in software mode.
In response to Hiro the Dragon King
Hiro the Dragon King wrote:
If the developer wants to use window transparency, that is his choice. He is not doing something wrong.

Using the interface in pretty much any way is doing something wrong. Once the Flash client comes out (if it ever does...) interfaces will be completely obsolete.
There isn't much to disagree on. The Flash client will not support interfaces. Since BYOND is fail, a Flash release pretty much guarantees you a better chance at success, but won't be possible if your game is interface intensive.

Are the letters and puzzle pieces in those games interface windows?
No, but without the interface, nothing in that game works. Ultimate Jigsaw uses the interface, er, manipulation of the interface to hide the main window, allowing the visibility of two panes that can switch focus. The two maps can also be stacked vertically or horizontally. In the LetterBox, the interface is used for the chat, help, players, and soon, the creation and deletion of objects and the addition of shapes, numbers, and symbols. That's not to mention HDK Mouse And Keys, which is the library both of them are based on, using the ability to place and modify browser elements to grab and measure mouse coordinates, client variables, and left and right modifier keys.

The interface isn't the devil. While it's not always pretty and not entirely intuitive, when used correctly, it can be an angel.

Falacy wrote:
Are the letters and puzzle pieces in those games interface windows?
No, but that reminds me of an idea that I once had...
I am incredibly interested in this as well.
Bumping.
There is no status update. At present we have no plans to switch back to using quad-based drawing, which was problematic for us in the past, and as far as I know transforms are not supported innately by the sprite renderer. We may revisit it, because I'd love this myself, but it's not on the priority list.
Page: 1 2 3