For a while now I've had the idea of making a fangame combining Touhou and Terranigma. The basic premise is that Keine, living in an equivalent of Crysta, travels to Gensokyo by the Elder's orders. Instead of helping mankind follow history, she would help Reimu (and Marisa) enact the equivalent of the Windows series games, recovering the cast and landscape from the world-shattering end of the PC-98 era, and all the while being manipulated by Dark Gaia, etc.

This is something that I'm certainly not able to do by myself. I'm no ZUN, so the absolute limit of my talents would be to do the game programming and story writing myself. I wouldn't stand a chance at doing the texturing, spriting, music, sound effects, game design, etc. Honestly I'd rather not even write out the story beyond the outline, since my writing skills aren't great either, nor do I even have most of the bigger details properly thought out. However, right now I'm not asking for help in any of those areas. I've seen way too many projects start up and fail immediately because of lack of direction, no pre-existing base, etc. This isn't even limited to /jp/-esque stuff. Basically, I'd like to have something to show off before asking strangers to commit their time to some project that had nothing to do with.

Then there's the problem that I don't even know how to do that. I've never gone any game programming. I know C and more-or-less C++. However I've never really used any graphical libraries, nor do I know any of the drawing techniques for even the simplest stuff. The one attempt at game programming I have tried resulting in ~30 FPS while doing nothing more than drawing tiles.

So what I'm asking for is some help in making a simple proof of concept, i.e. an engine capable of moving Keine around within her multi-room house (the starting point of the game) and chatting with people, probably with completely unrelated sprites and no sounds whatsoever. I have looked at some tutorials I found on the net for basic game building, graphics drawing libraries (D3D briefly, then SDL after someone mentioned it on /jp/, and ClanLib a few days ago) and a few frameworks, but I don't really know for sure what I should use. I'd much prefer using C++ over some useless crap like PyGame or even Java. I don't object to using a 2d game framework as long as it's powerful enough to emulate Terranigma gameplay. Actually, I'd prefer a game framework if it was powerful enough, although none of the ones I looked at seemed useful.

Again, I'm not asking for a dedicated volunteer at this point, since they'd probably just get discouraged by my own lazy and unmotivated ass. Having a job doesn't help me here, either. I'm not going to object if someone thinks that what little I've said is awesome enough to want to whip my ass into shape, but what I'm really looking for is a lot more information and suggestions on how to go about handling the stuff I've never handled, i.e. collision detection, multi-layered background rendering, animated sprites, direct input, etc. Recommendations on what libraries/frameworks to use, tutorials/books to read, advice, telling me I'm going about this all wrong, etc would all be greatly appreciated.

>>1

>This is something that I'm certainly not able to do by myself. I'm no ZUN, so the absolute limit of my talents would be to do the game programming and story writing myself. I wouldn't stand a chance at doing the texturing, spriting, music, sound effects, game design, etc.

I'm pretty much in the same boat as you. I'm a programmer that lacks art, music, and writing skills. I've never played Terranigma before but if it's like most RPGs, making an engine for it would be trivial for me. (I boast.)

If it's a 2D game you should consider using SDL or Allegro for graphics. And if you were to 'borrow' some of the sprites from various RPG maker programs it would cut your development time in half. It's a shame I'm too busy with my own projects right now to lend a hand. If you're still working on this a month from now I might be able to pitch in.

So stick with SDL, then? Alright. Actually, I could probably borrow sprites from Terranigma. That'd probably be best for placeholders, since I would be planning to replace the character sprites with something of about the same size.

Actually, could you share anything from your projects? I just realized that I never did bother looking for any actual code examples, just tutorials and demos (and even then, a lot of what I found was stuff for D3D6 or so).

And you should give Terranigma a try. It's a damn good game.

>>3

>Actually, could you share anything from your projects?

Such as?

>>1

> more-or-less C++

Nobody really knows sepples.
But, good luck OP.

>>4
A concrete example of a main event loop and graphics drawing. My last attempt (at something different) stopped when I had to design a map editor, and that'll likely be a huge pain here too, especially since I really don't even know how to create the format to represent the backgrounds, walkable terrain (Terranigma supports diagonal and flat impassable surfaces so a simple grid won't work. Chrono Trigger also does this), and whatever else I'll need in a map format that I can't even think of.

You said that making an RPG engine would be trivial, so I'm assuming you've done so before. Those three things are what I'd probably have the most difficulty with, with the map editor being the worst (especially since I don't know how useful an example will actually be). If you have something like that you'd be willing to share it'd be great.

>>6
Only one problem. SDL isn't my forte. At best I probably only have 3 hours worth of experience with it. My experience with allegro on the other hand is decent.

>>7
Oh, sorry. I figured that you were using SDL for your projects.

From what I've heard, SDL is slightly faster than allegro. And on top of that it has more 3rd party support (e.g., add on libraries).

>>6

>map editor

No offense but just seeing that word in that context just reeks of code monkey to me. A map editor should come last. Designing levels and thinking of gameplay concepts are the easy part. Until you get the harder stuff done you need not worry about a map editor. A map editor's only purpose is to make the tedious work less tedious. Personally, I've never sullied my hands with one because they're beneath me.

>>1

>The one attempt at game programming I have tried resulting in ~30 FPS while doing nothing more than drawing tiles.

Sounds like you made the common data loading error. Image files such as PNGs, JPGs, and BMPs only need to be loaded into the memory once.

Here's an engine template:
http://pastebin.com/Uhi7QfsA

>>11
Shouldn't have been. All of the images were loaded in a class instantiated before the while loop. There was no call to any file loading after the main while loop begins. As far as I can tell, I was already following that template, except I didn't have a CPU limiter at all. IIRC, when for testing I made it so you could scroll past the map and draw nothing except a blank canvas, the frame rate shot back up. I'd assume that if I was causing memory leaks I'd get bad FPS no matter what and it'd just continue to go down as the program ran. I started the program, ate dinner, and was getting the same mediocre FPS that I had when I left.

>>10
I wasn't trying to design the map editor to work on level design. I simply wanted to be able to add stuff to the map format and make sure it was displaying properly, such as walls. Not that I even got that far.

>>12
Assuming you've already gotten started with the project you should make the source code available to the public. That way people might be able to help you.

>>13
I haven't. What I'm talking about is for something else that I had started over half a year ago, for a different game. All I did was some tile rendering with scrolling, a message window, and some mouse support with a custom cursor. And it gets shit FPS despite being so minimal, and I gave up primarily because I really didn't know how to continue, hence making this thread. I guess I could share my earlier attempt, maybe someone could find why the FPS is so dreadful. Any mistakes I made there would probably just be duplicated in the future.

Here's the VS project. Hopefully I zipped everything necessary; can't say I've ever tried to share a VS project before. Pay no attention to the naming scheme.
http://www.mediafire.com/?izfmkzmkbzz

I probably won't start until a week or so after Reitaisai. I'm gonna be uploading shit off share, plus I want to try out DS and start sucking at it.

>>14
I almost forgot how messy VS was. I'll be getting started with SDL in a few months. Hopefully by then I'll have some spare time to help you. Also, I think your FPS problem has something to do with your FPS counter. Try a different approach to it.

I guess I'm going to need a better hint than that, as I can't find what the problem is. FPS should be as simple as the number of frames rendered in one second. 1000 ticks matches up to 1 second according to my count, so the only possibility I can think of is that I'm not counting every frame. And if that is it, then I have no clue how to fix it.

Bump.

So I've done some work on this. Used as much of the code from the previous attempt as I could, but a lot of it is new. I have the program set to initialize a fake map with a small tileset and it gets drawn properly. I have input set up so that the 'player' (the green dot) can move around the screen. No collision is set up, so the dot can freely move off the world or even completely off the screen. The map is larger than the screen on the X axis, and the map scrolls to follow the character as long as it doesn't go beyond the edge of the map.

And I naturally still have my old problem. I'm getting 30 FPS again. I added an FPS limiter this time so it won't go beyond 60, and I was getting nearly constant 60 before I extended the size of the map. Tiles off the screen aren't being drawn from my for loop, but it's still slowing everything down. Hell the SDL_FillRect() call I have to flood the screen with black seems to be worth a ~10 FPS hit (removing it without changing anything else results in ~40 FPS rather than ~30). I know my computer is a piece of shit, but there's no way that's the reason I'm getting such low FPS. I must be doing something wrong in the rendering. Should I be drawing tiles in some way other than just calling SDL_BlitSurface()?

I'd appreciate any advice/solutions for this. Here's the VC Project.
http://www.mediafire.com/?kzlwjtkhytd

So it's been about a month since I've started working on this.
New rar of the project: http://www.mediafire.com/?eawydwhcmmm

I have basic collision working, and a title screen that shows up at the start instead of going straight to the map. It's not perfect but it works fine for now.

I think the next item to work on is to finish work on the tiling. Right now I have nothing but the background tiles. Terranigma uses at least three layers; the background layer, another layer drawn on top of the character sprites, and then another layer (two?) used for special effects, e.g. crystal blue (drawn on top of the player) or light coming in from a window (drawn below the player). Then there's the complex tiles, such as a bed in Terranigma, which are always put together, so I don't know if they should be considered a single different-size tile or not. And then animated tiles...
I'll obviously need to modify my data structs to handle multiple layers, and serialize it all so it can be stored in map files, but since I don't really know what I need I can't really design anything.

And I still have the low FPS issue. Googling seems to imply that there is no solution to this in SDL, so I assume that the only way to get a decent framerate is to render using OpenGL. I haven't looked too extensively into this, but since I'm really only doing flat 2d textures, I think it'll just require creating a square quad and texturing it with the tiles.

Could certainly use a hand here.

>>18
Keep up the good work.

Thanks for open-sourcing it.
I can't build the project (no VS or tchar.h on linux) so no testing this myself. You already found SDL_DisplayFormat, good. Do you get low FPS all the time, or only when the map is scrolling? If nonscrolling, dirty rects, but that doesn't help when scrolling the whole map. Does a smaller window/lower resolution help any?

> C++ over some useless crap like PyGame

Why? A better language makes things easier, and players don't care if you're an EXPERT PROGRAMMER using an EXPERT LANGUAGE. This is especially true if you're just starting with a prototype. Even if you end up using C++ for the final project, you can learn how other languages/frameworks solve a problem, and copy their approach over to C++/SDL when it makes sense.

Here's Love2d in Lua doing a scrolling tile map. 150-180 fps for me with no changes, 80-90 if I change it to fill the whole screen with tiles.
http://love2d.org/wiki/Tutorial:Efficient_Tile-based_Scrolling
It's built with C++/SDL and is open source, so you can probably copy this approach to your C++ with a bit of effort. I think the idea is to render all the background tiles to one large surface in advance, instead of blitting hundreds of small tile surfaces each frame. I've not read the C++ behind it, I could be wrong (I'm not much good with C++ anyway), but this does show it's possible.

Game programming is hard. Good luck.

>>20

>Why? A better language makes things easier, and players don't care if you're an EXPERT PROGRAMMER using an EXPERT LANGUAGE.

Because I don't consider Python to be a better language. I don't consider it to be a very useful language, and certainly not a language suited for game programming. Furthermore, a project at work had me working with a guy who was a fucking python fanatic (and I quote, "The one true language"), so that just left even more of a bad taste in my mouth for that language.

>Do you get low FPS all the time, or only when the map is scrolling?

All the time. Considering the speed loss I get from JUST doing SDL_FillRect to blank the screen before drawing, I'm just getting the feeling that I'm just drawing too much data onto the screen at once. I don't have any method for dirty rects, and since the map does need to be scrollable I'm not sure how much they would help me.

Lowering the resolution would cerainly help. However I'd say that is just delaying the problem. Even my crappy computer should be able to get 60 FPS on a 1024x768 game 2D game in window mode (especially since I can get 60 FPS in 1680x1050 fullscreen in an old 3d game). I'm assuming that the problem is just with SDL not being fast enough. I'll be worried if I still get crappy FPS after making the switch to OpenGL. Then I'll lower the resolution.

>I think the idea is to render all the background tiles to one large surface in advance, instead of blitting hundreds of small tile surfaces each frame.

I did think about rendering the entire map into a surface and drawing a portion of that onto the screen; that should help some, but I don't know how much since I'd eventually need support for animated surfaces, foreground and background, and dirty rects for where the characters move. I don't have time to check the example out today, but I'll see how complex the code is later.

>Game programming is hard. Good luck.

Thanks.

Ok. I'm giving up on trying to use OpenGL. I finally managed to get the little arrow (a 16x12 image) on the title page to draw using a bound quad. However if I try to use a quad on anything larger than about 32x32, I get absolutely MASSIVE slowdown to the point where I thought the GL code was infinitely looping when trying to draw the 1024x768 splash screen. Then I found out I was actually just getting around 1/32 frames per second and wasn't giving it the necessary half a minute to load. I tried using glDrawPixels as an alternative, but that literally does nothing and won't even give me any kind of error message to say what I'm doing wrong.

There's no way I'm going to be able to write useful OpenGL code just from reading tutorials on the net, even if all I'm trying to do is draw flat images. I don't have the time to properly learn OpenGL, especially not without any prior knowledge of the necessary mathematics. I'm just going to have to stick with using SDL.

Still working on this. Here's the updated project for anyone interested.
http://www.mediafire.com/?gljyjlitt4o

Added simple animations (the 'river' is animated now, using 7 frames). Added a second layer of rendering; the topmost tiles of the well are drawn over the player. Added some base code for NPCs, and drawing the characters in order so that they'll "overwrite" a character above them. Added a second map and transitions to or within maps, e.g. for walking through a door. It's all instantaneous, unlike in terranigma where you automatically walk into the door for a second or so before fading out and then fading into the new map. That's a trick to add much later...

And now a question for anyone who has a good answer. What's a good way to store the spritesheet for a character? Tilesheets are simple because they're always the same size, making it simple to stick a bunch of them into a single image file and only select what is necessary. Sprite frames are much more difficult, as they aren't all the same size. The image size will change constantly, as characters are drawn narrower when facing left or right than facing up or down; attack animations extend outward into one (or more) direction; stuff like the dying animations go from "tall and narrow" and "short and fat". And worst of all it looks like Ark's sprite in Terranigma is actually composite, especially for attack animations; there's the main body, the weapon he's holding (and changes color, which is probably just a palette swap), and also his hands. So what's a good way to keep track of all these different-sized images I'm going to need? Just lump them all together in a single sheet like the tiles, and pad them all to the largest dimensions so they're all the same size? Lump them together and store the exact dimensions of each individual segment? Store everything as an individual image in an archive format and use that to separate everything? That's all I've been able to think of myself. I'd think that the last solution would be simple and not too wasteful. I'd appreciate suggestions for this.

>>23

>Just lump them all together in a single sheet like the tiles, and pad them all to the largest dimensions so they're all the same size?

This seems to be the most straight forward solution, I'm however no expert on this.

I decided to go with the archive file approach. I remember looking at Doom's sprites years ago and they all had names; I figure it's easiest to name an individual frame this way, and using a naming convention will make animations easier.

On that note, animations work. Ark in the screenshot flickers between having a magneta background and a white background. I don't know that my implementation is perfect, but it seems to be. I tried asking on Pooshlmer for sample Touhou-related sprite data, but no one seemed interested enough to put the work in. I'll have to use existing sprites to do the real animation tests, which should work fine but won't look as cool.

I finally added dirty rects as well. The title uses a very simple implementation and that brought the FPS up to 60. The game uses a backbuffer that's the size of the entire map, redrawing the tiles or characters as they become dirty, and a portion of it is rendered onto the screen. Despite needing a fairly large surface for this buffer, it doesn't seem to impact performance itself by that much; the 'huge' map doesn't affect the fps much more than the firstmap, despite being much larger. The problem is that I'm fairly certain I know have two backbuffers. I don't need the SDL default one now, but since I'm not explicitly turning it on I don't know how to turn it off. Does anyone with SDL experience know how to disable the software backbuffer, or to properly replace it with the larger custom one?

Updated project:
http://www.mediafire.com/?o0mnnbj23yy

>>25
No clue.

Bump because it's been 3 months.

Project: http://www.mediafire.com/download.php?dkf5suda26muypb

The main additions I added are basic dialogue support, as shown in the screenshot, and improved collision. Dialogue uses a relatively simple string of raw characters and some control codes to do fancy stuff like changing the read speed, waiting for input, etc. The collision now uses reactive instead of predictive collision, since I couldn't get good predictive collision to work. If you moved into a wall, then you get moved out of the wall. Simple. Only problem right now is that it's possible to walk right through the corner walls, but I'm pretty sure I had that problem earlier anyways. Walking into an NPC will now also cause them to face you, which is necessary to talk to them now.

Still looking for people who actually know what they're doing. For example, drawing the dialogue window results in a ~10 FPS hit. I literally just finished working on it so I haven't had time to make it do something besides draw every single frame, but I'm sure I'll still only be able to knock it down to a 5 FPS or so hit; still very noticable.

Project: http://www.mediafire.com/?15wa4sfvkbazv7p
I tweaked the project to use relative directories rather than absolute, and SDL is included as well so it should load right away on any machine with VisualStudio. Probably. I'm making the archive with a Perl script now, and it trims out all of the compiled junk and the Intellisense file I had been including.

Went and implemented the 2nd method for dialogue scripts, with one small change. Labels have a name (like in the example) and then also an expression to evaluate, separated by a pipe, e.g. {apologized|$apologized}, {sorry}, etc. This way all of the labels are named and the expression that needs to be evaluated to reach it (if any) is right there with the declaration. Presumably that'll be easier to work with than a lookup table.

The grammar for the script files is mostly complete; just lacks String primitives (which I plan to only allow for function calls; variables are set up to only be integers and never strings) and jumping directly to a label without prompting for a choice, with or without a condition to evaluate. Damn near everything else works though; the script tags are properly turned into a compiled text that the C++ code can handle, variables can be stored in map (a single level), area (a collection of levels) or global scope and retrieved. Expressions can be evaluated, and the expressions support every integer operation I could think of that might be useful.

I also went through and tried to fix the memory leaks I had. I think I got a lot of them but there's still a noticable increase at times when switching between levels. Is there a good way to do some sort of profiling to determine when I'm allocating memory, freeing memory, and more importantly not freeing memory/deleting objects? I've never worked on an application where memory management was actually important, nor an application of this size, and it's quite annoying to see how many damned leaks I have (or had) already.

And as usual I don't know where to go next. I could add NPC movement. Or I could revamp the shitty dialogue rendering to not be terrible, and to include stuff like rendering text in different colors.

Interesting project. After a small amount of hacking I managed to make your code compile and work under Linux; props for using only portable libraries in your code.

My FPS in game is about 40, seems that SDL is indeed pretty damn slow. I even tried omitting all drawing and just flipping the screen, and the FPS was still only 45.

Based on this, I would recommend you to reconsider your decision to not use OpenGL. If you are just blitting tiles, using OpenGL to do that shouldn't be much harder than using SDL. I don't know what you did wrong earlier, but normally drawing in OpenGL should be pretty blazing fast, assuming your graphics card is from this century and you have newish graphics drivers installed.

>>30
A little more on drawing performance: I noticed you used 24-bit colors. I don't know how color depths work on other platforms, but at least for me changing the display depth to 32 bits increased the FPS to about 66 (after disabling the 60 FPS limit).

>>30
>>31
Increasing the bit depth raised the FPS? That seems odd, if only because there'd be more data to copy over with a larger bit depth.

How exactly did you change the bit depth? I tried changing the line DisplayHandler = new Display(1024, 768, 24); to DisplayHandler = new Display(1024, 768, 32); and went from 230 FPS to 88 (new computer). Unless you did something else, I can't fathom how increasing the bit depth would make it go faster.

It's not that I decided against using OpenGL, it's that I could figure out how to get it to work. Whatever I did wrong just made the thing go so goddamn slow I thought I had an infinite loop... and then I realize I actually had about 1/30 FPS. I'm guessing I was doing something equivalent to loading a bitmap, rendering it, deleting it, and repeating this process only with quads.

The FPS problem is definitely something that needs to be fixed eventually. OpenGL, once correctly implemented, will probably make everything go blazingly fast. Or possibly it's just my bad rendering code, and enough tuneups would give acceptable FPS on any machine even with SDL. However at this point in the project I'm really more concerned with actually getting stuff to work at all, not trying to get it to work with good FPS. Right now I'm trying to get as much stuff that can be seen in Crysta implemented (doors, running, jumping, falling down ledges, ...) and see if I can release a tech demo at some point. Hopefully that will be able to attract an artist. Or a more experienced game design programmer. Or someone that knows OpenGL.

>>32
I did just what you tried with the bit depth; I assume the reason my speed increased is that my system is using natively 32-bit colors, so 24-bit colors needed an extra conversion that took time. Based on your results I guess this is not usually the case in Windows so using 24-bit colors is better.

> I'm guessing I was doing something equivalent to loading a bitmap, rendering it, deleting it, and repeating this process only with quads.

When drawing with OpenGL, you usually load the bitmaps as textures once and use those textures many times (ie. don't reload them every frame and especially not every tile). If you reloaded textures more often, that might be part of the slowdown (though 1/30 FPS is so damn bad that I suspect you have managed to fuck up something else too). Additionally, changing textures might be slow, so it is better to have a whole tilemap in a single texture and render part of it for each tile instead of changing the texture at every tile.

>>33
The loading of bitmaps repeatedly was an example. I meant something like "To render 20 tiles, I create a set of quads for each tile, attach the image, destroy the quads, and move on to the next tile." - and I have no idea if I'm supposed to do that or not.

I did save (most of) the project, however trying to run it now on my new computer gives me 60 FPS, even with the full size bitmap. I honestly can't remember at all what I was doing or how wrong it is, only that most of the openGL stuff would be found in the Texture class I added. This is from an old version and I severely crippled it while I was trying to test stuff, so really the only thing that "works" is the title screen.
http://www.mediafire.com/?gp1511vnqx2fxm6

It's been a full year since I started this thread, and just under since I actually began work on the project. Huzzah! Here's to hoping that th13, once fully released, will have a final boss that makes a better Beruga than Byakuren.
Project: http://www.mediafire.com/?t4be9j7evi1lqsa

Plenty of new stuff; there are now two NPCs on the map. The cultist is showing off the waypoint system and constantly moves in a square. Elle is on the wanderdist system and moves randomly around a small section of the map. Ark's movement has been changed entirely to test forced movement and the waypoint creation; his movement is restricted to tiles now (which is necessary for cutscenes and walking through doors).
And I finally fixed some of the damned rendering glitches I was noticing. Damned dirty rects.

And of course I went and refactored a lot of crap. Added the base classes Object, Animatable, and Interactable for all objects, objects that can animate, and objects that have collision. Characters are both animatable and interactable, so I now have lovely diamond inheritence.

And the archive files were completely redone to a new, much more complex format. Instead of simply throwing in a bunch of files, there's now defined animations composed of frames composed of 1 or 4 images. The images and frames all have metadata as well, which I will eventually be able to use for stuff like mirroring images, offsetting the drawing position (watch the the left/right player movements for the best example. When Ark moves his legs out the image is significantly wider than standing still, so it looks like he's constantly moving back and forth). And each frame can now have an associated function to call, using a new Python script to autogenerate C++ into the project to add functions for every specified.

The frame events are somewhat modeled after what I remember seeing in Doom. I used to play around in DeHackEd, and I recall the events associated with frames to fire the gun, explode a barrel, give extra health, etc. Certain things are definitely frame related - when this frame is displayed, do this action - and trying to do it in parallel to displaying the image in code would be a giant pain in the ass. So it's handled in the metadata, specified as a string, and the Python and autogenerated C++ handles the conversion from string to integer to function pointer, and then the function (if any) is called whenever that frame is displayed. There's a sample function in the project now, some of the movement frames for Ark will create a smoke puff that appears and then goes away after playing the animation once.

I honestly have no idea if this is really the best approach, but to me it appears necessary to have functions be called when certain frames are rendered, and what I have now should be able to handle what's needed. Probably.

Updated project:
http://www.mediafire.com/?gprbitb6xpj779k

Also, it looks like I never posted the "design doc", so here's that as well. It's extremely rough and missing a lot of details, but should give a general overview of what I'm trying to accomplish.
http://pastebin.com/KsgeucaB

Still working on this slowly. I've been trying to add the majority of the features the player sees in Crysta to try to put out some kind of tech demo. I should have most of the stuff done for that now, e.g. jumping, running, falling down ledges. Doors will be added next, and the minor stuff like eating random bits of door or throwing stuff can be left out for now. The movement code is getting clunky but it works for now. The animations are also extremely bad, but that's simply me not wanting to waste time stitching together the images when they're just placeholders.

Since I'm getting close to creating this tech demo, I think it's about time I created a map editor. Any suggestions for how to create one? I've never even used a map editor for such a game, let alone created one myself.