[DeveloperX]

[DeveloperX]

[Adam]

No one is going to buy a game just beacuse it costs a buck. Thats why you need to do all these little annoying things to make the game worth their time and effort to purchace.

Customers don't care what point you proved to some guy. They'd prefer that you made the game as good looking as possible.

Craziliy enough, by following the link i sent you above and having a look around you would have gotten a link to this site. But since we are not big on research, this seems like a place that will take peoples money without requireing them to join.
_________________
https://numbatlogic.com

[DeveloperX]

[tcaudilllg]

Well I'll buy a copy shortly, not because I think it's a good game (because I don't) but because you seem dedicated to making it better.

I noticed that it's using the PC speaker. :P Try this instead. It may not work because it is untested for reasons that may be immediately obvious. If it doesn't then feel free to debug it, shouldn't be hard. Also, programming SoundBlaster sound effects is simple, and XP compatible if it's done right. See the SoundBlaster programming guide in the PCGPE to find out how to program large, detailed effects, although in the case of this game the following may suffice.

[Adam]

[DeveloperX]

[DeveloperX]

[Adam]

He said that he thought you were dedicated to making THIS game better. As i understand you are pretty much dumping it as is and moving on.
_________________
https://numbatlogic.com

[tcaudilllg]

Well I just finished a tile scrolling engine in JS, so maybe I can help! :)

The approach I used--and the simplest possible--is to blast an entire screenfull of tiles to the screen at once. Try storing the tile data in GET simple binary first, then PUTting the data onscreen one tile at a time. You could create a two dimensional array vector for the map, and use two loops, one for the first axis and one for the second, to match the map data at each map coordinate with its corresponding tile and draw the tile onscreen. In this case you would have to load all of the tile data into another array vector; extract the tile data for the map coordinate in GET binary form; and PUT the data onscreen at the screen coordinates that correspond to the map coordinate.

To scroll the tiles one-by-one, one strategy is to make the entire map larger than one screen. Map coordinates are drawn onscreen starting at an offset on the larger map and continuing down to the limit of the onscreen Y coordinates and continuing left to the limit of the onscreen X coordinates. To scroll the tiles, this offset is increased and the display is redrawn.

Pixel-by-pixel tile scrolling is far trickier, because PUT does not function at coordinates that are offscreen. The easiest method is to cover up the farthest tiles in the direction of the scroll. That way when the tiles scroll they seem to cleanly slide into the darkness. Alternatively, you can try using smaller slice tiles along the screen borders to represent the tiles that are scrolling offscreen. Just thinking about that makes my head spin.

Writing directly to memory--you can do this easily in C/C++-- makes pixel-by-pixel scrolling much easier. The map tiles that surround those drawn onscreen are drawn to a two dimensional array vector that is the length and width of the display combined with the length and width of the tiles times two. In this case, tile drawing would start the map coordinate offset + 1 in both directions and would end at the map coordinate offset - 1 in both directions.

To effect pixel-by-pixel scrolling you would displace the onscreen tile coordinates by one in the direction of the scroll for every pixel that in scrolled.

EDIT:
I just realized that the tile slicing technique is totally unnecessary. The pixels on a tile are analogous to the tiles on a screen. By manipulating the pixel data on a tile before it gets to the screen, the tile can effectively be scrolled. To illustrate, draw the entire tile display to a extended tile screen as described above, and then, tile by tile, write the screen data to GET vectors starting at the offset in the vector that is the starting offset of the viewable imagery displaced by one pixel in the direction of the scroll. Because there is a lot of data transfer activity, this procedure will be quite slow. I don't recommend it for QB at all. However, in cases where tiles are the only available resource for onscreen imagery, it should work.

[biggerUniverse]

Did you post this in the wrong thread?
_________________
We are on the outer reaches of someone else's universe.

[tcaudilllg]

I was responding to DeveloperX. :) But yeah, these techniques are quintessentially universal to scrolling engine development, so if it was desired they could be utilized by the convention project.

[tcaudilllg]

Uh Adam... why are you using my picture...? :?

[Adam]

Beacuse it's teh sexy.
_________________
https://numbatlogic.com

[Happy]