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 - Richard Kain

Pages: [1] 2
1
Help, Errors, FAQ / Re: Hey- Character Portraits in messages?
« on: 2008-05-13, 08:19:26 PM »
Really!? Perhaps I should have another look at 3.0, then. I am absolutely not going to upgrade to Vista. But if I can get 3.0 running on XP, I would certainly like to take advantage of some of its features. Specifically, I know that 3.0 has voice recognition functions that would make implementing a lip-sync system fairly easy.

2
General Discussion / Re: 3D SGDK2 Game
« on: 2008-05-13, 10:44:03 AM »
You should look more into the "scrolling" aspects of the SGDK2.0. Using layered scrolling backgrounds (in conjunction with alpha-masks) is a great way to give 2D games a quasi-3D feel. The SGDK2.0 has excellent support for layered scrolling. Using this technique effectively can convince the player that your game is much more 3D than it actually is.

3
General Discussion / Re: OpenGL Conversion
« on: 2008-05-13, 10:40:05 AM »
Yes, the quality of the games graphics are not really limited by the technical aspects of the SGDK. (ver 2.0) In fact, it is probably considerably more capable than either the DS or the SNES. The real difference is in the artistry. Most high-quality 2D SNES and DS games have entire teams of artists working for months on their assets. They look better because they have some highly skilled and practiced artists giving them their all for a considerable chunk of time.

Many SGDK2.0 projects are going to have only one person working on them. Even if that person happens to be an exceptional sprite artist, they are still going to be at a huge disadvantage when compared to commercial teams. In fact, you should probably be flattered if your game is being compared to SNES graphics. It means you're being favorably stacked up to some of the most beautiful 2D games ever created. (after the SNES, 3D started to really come into vogue) Just keep practicing with your art, your work should steadily improve with practice.

4
Help, Errors, FAQ / Re: Hey- Character Portraits in messages?
« on: 2008-05-13, 10:27:56 AM »
If you have any experience with C#, it shouldn't be too hard. Like he said, all you need to do is extend the message box a little and fill the extra area with some frame graphics. It wouldn't be too difficult to animate the frame graphics using a series of sprites to make it look like the character's mouth is moving as well. I've always been pretty keen on this sort of thing. Obviously, the ultimate goal would be to enable full lip-syncing support for "talkie" characters. Your best bet for that would probably be Papagayo from Lost Marble, or perhaps the .Net framework 3.0. (although I wouldn't really recommend .Net 3.0, as it requires Vista)

5
General Discussion / Re: OpenGL Conversion
« on: 2008-01-29, 05:36:03 PM »
but do i understand this right, if you once made the change to open gl, i guess you will develop sgdk2 in this way further...
someone who wants to use directx, has to stay on the current version.

Also, it is worth noting that ultimately, this would only really effect...well...effects. Higher-level shader effects would be the only real difficulty in porting between the two different APIs. And for the most part, I don't think most users of SGDK2 are really looking to push graphical effects quite THAT far. I know that I'm primarily focused on gameplay elements, and eventually sprite artistry. Shader effects are way, way down the line in my development cycle.

6
General Discussion / Re: OpenGL Conversion
« on: 2008-01-28, 04:52:13 PM »
Ideally, the low-level graphic calls will be what is primarily effected. I'm pretty sure that the fmod library being used is not reliant on DirectX, so it should be unnaffected. The player input is an issue, as you would need to substitute something other than DirectX in order to fully separate it from Microsoft's initiative. The ultimate goal of using OpenGL is to disconnect the engine from DirectX, thereby freeing it up for porting to other platforms.

Naturally, there's no reason to abandon code already written. If an OpenGL options is added in the future, I'm sure that the Windows version of the SGDK2 will still allow you the option of using DirectX. You just need to put conditionals in the right places, after all. And again, this is just experimental at the moment. The SGDK2 author is still experimenting with getting OpenGL working on the engine. (I believe he is using the Tao library at the moment, which is friendly for cross-platform C#) If he feels it is impractical, I'm sure that he will likely focus on other features to develop.

7
Help, Errors, FAQ / Re: wrap-around map
« on: 2008-01-25, 03:02:54 PM »
Well, and this is the difficult part, you would ideally have your player sprite separate from the vertically scrolling layer of the map. I'm not exactly sure whether or not this can work in SGDK2, as I haven't gotten to that part yet in my own projects. If the player sprite were on a separate layer, you wouldn't have to worry about enemy collisions being processesd multiple times, as there would only be one instance of the player. It's not often that you see a game pull off the kind of effect you're describing. I do remember one NES title called "MetalStorm" that did exactly that, though, so it certainly should be possible.

8
Help, Errors, FAQ / Re: wrap-around map
« on: 2008-01-25, 01:55:01 PM »
Oh, yes, this is actually quite easy. All you have to do is program the engine so that a new instance of the map is created and placed at the far end of the existing map. That way, as the player advances through the level, the offscreen instance of the map will be deleted, while the upcoming instance is appended. At any given time, there would be three instance of the map. In that way, the level could scroll indefinitely in either direction. Of course, it would almost certainly require some additional programming. (ie, I don't think you could do this just with the visual rule editor, but maybe I'm wrong)

9
Help, Errors, FAQ / Re: Multiple masks?
« on: 2008-01-25, 01:48:10 PM »
I must be missing something. Aren't sprite definitions made up of framesets? And aren't framesets in turn made up of tilemaps? And isn't it true that each element of a tilemap is able to have its own alpha values? As such, shouldn't it be possible for every frame of a sprite's animation to have its own, unique alpha mask? And can't collision be tested based on the sprite's alpha value?

So if you are using exact collision detection based on the sprite's alpha values, don't you just need to make sure that each frame has its own unique alpha value? Or am I just crazy with this assumption? I've been importing a crap-ton of sprites into the trial project that I'm playing around with, and every single frame has its own unique alpha values.

Also, I've been thinking that double-checking for collision detection would probably be the most efficient method for exact collision testing. For the more experienced users here, tell me if I'm wrong. If you were to use an "If" statement to test for basic rectangular hit detection, you would get the most efficient collision detection in terms of speed, yes? And if you put a call to alpha collision detection within that "If" statement, that collision check would only be performed if the rectangular check had evaluated to true, correct? Ideally, using this method for any instances of exact alpha collision detection would result in better performance, since the alpha collision check would only be performed if the faster rectangular checking had already proven true. Just tell me if I'm off base there, because I'm going to be getting more in-depth on collision testing in my trial project soon.

10
Help, Errors, FAQ / Re: Custom tileshape
« on: 2008-01-24, 04:56:25 PM »
I'm actually interested in creating tile shapes that have the corners clipped off. That is to say, they would have diagonal values where the corners would be. This is so that there could be a bit of easing whenever the player runs into a corner. Right now, when the player attempts to go through a passage that is the same size as them, they have to hit it dead on. (or they bump into the edges around it) If I was able to bevel the corners near passages like this, it would be possible for me to "ease" or "guide" the player into these tight spaces.

11
Game Development Artistry / Re: drawing characters
« on: 2008-01-22, 02:29:34 PM »
I personally am going for more of a 2d look which Blender isn't that great for.

Yes, this is very true. If you want a traditional 2D illustrated sprite look, Blender, and 3D in general, is the wrong way to go. No matter how much you tweak 3D models, they will always have a bit of the "Donkey Kong Country" look to them when you make them into sprites. Some clever work with ramped shaders and outlines might help, but there will still be a disconnect. For the illustrative sprite look, there are no shortcuts, and you're just going to have to draw the buggers out.

Using 3D models for your sprites is for designers with less traditional art backgrounds, or who simply can't afford to draw all their sprites. The biggest advantage of 3D sourcing is the animation efficiency.

12
Help, Errors, FAQ / Re: limited frame rate
« on: 2008-01-22, 02:22:55 PM »
I was under the impression that the base-line framerate already was capped at 60fps. At least, all of my trials have run at no higher than 60fps

13
News and Announcements / Re: SGDK 2.1 - OpenGL Support
« on: 2008-01-18, 01:46:42 PM »
Hmmm...that makes me think of something. One of the things I've been wanting to do with SGDK2 is create a game with a non-standard screen aspect ratio. That is to say, it would be vertically oriented, rather than the standard 4:3. I would want to do this because I am interested in using SGDK2 to create a shmup. And many shmups scroll upwards and have vertically oriented screens. (screens that are taller than they are wide) The existing source code doesn't allow for this, and I can't seem to save edits that I make to the source code either. But I know from looking at the source code that this should be possible. Can I fire my game up in Visual Studio and add new screen resolution options?

14
Projects / Re: Calling for a name
« on: 2008-01-16, 03:10:41 PM »
I think "Favovian Freighter" is a good title. Using words from a different language in a title is a common tactic. And in this case, I think it fits very well. A Zeppelin naturally inspires the thought of exotic locales anyway. (the word "zeppelin" has always evoked thoughts of Europe in me, for some reason) The alliteration of the title is catchy in a good way. Also, the word "Favovian" is both exotic, and calming. It is full of softer consonants. It rolls off the tongue in a pleasing fashion. And naturally, "freighter" is right in line with the gameplay you've described.

Having a title immediately understood and obvious isn't always as important as making it pleasant. Heck, most fantasy titles have completely made-up names. At least Favovian is an actual word somewhere.

15
Projects / Re: Calling for a name
« on: 2008-01-15, 02:42:07 PM »
Omg. I still can't believe it, when I see it. When I have the time (school started back up) I am going to attempt to do this! Do you use the graphics editor that is built in SGDK2?

You can use the graphic editor. I gave it a spin and actually found it to be pretty darn useful. If there was anything that I would complain about, it is that it lacks a "preview" mode for tiled editing. It would be awesome if you could "preview" selected tiles to the top, left, bottom, and right of the tile that you are actually working on. These "previews" would not be editable, but simply graphical instances of graphic tiles you had already created. This would make it considerably easier to develop effectively tiling graphics. (since you would be able to line them up seamlessly with other tiles)

Aside from that, the graphics editor is very capable, and very good for sprite development specifically. It was wise to base SGDK2's graphics on the PNG format. It is the perfect graphic format for these types of 2D games. I tend to switch anti-aliasing off when I sprite draw, as having per-pixel control is very important to me. Also, I tend to zoom in to the maximum setting for individual sprite painting.

Pages: [1] 2