Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

TheMole

Members
 View Profile  See their activity

  • Content Count

    855

  • Joined

  • Last visited

Posts posted by TheMole

  2. Posted

    That thing is a WiFi bridge, and a bridge means that it will transparently connect one network to another. In this case, a network created between the lantronix and the doohickey on the ethernet side and your regular WiFi network and the thingamabob on the WiFi side of things. Typically, the dongle will be a DHCP server for the ethernet devices and a DHCP client on the WiFi network. It will 'mirror' the devices on the ethernet side of the bridge (in your case the Lantronix) with an IP address appropriate for the LAN network.

     

    All this means that it should surely work, but you will need to reconfigure some things. Shouldn't be hard though. Often, the devices with one ethernet port like the one you show here simply support just one device on the ethernet side of the bridge which tends to make setup a bit more straightforward.

    • Like 1

  4. Posted

     

    I think this model might work if someone is willing to invest the time. I don't care much about boxes and manuals myself, but I know they are important to many of you. Send me a private message if you have a proposal. I would find a cartridge release much preferable to a floppy disk release (especially since I don't own a PEB :)), but I guess the latter would be much easier and cheaper to produce and distribute.

     

    I would prefer cartridge releases as well (and I will commit to buy any new cart that is put out by the community), but that also implies a lot more work for you to make it all fit and switch banks to make it work on an unexpanded system nicely I guess. The boards can be made from the 64k board PCB's, the cases can either be reclaimed TI Invaders shells like with pitfall (Matthew sells them for 2$ a piece, although I'm not sure how many of these there are floating around) or 3D printed stuff if the quality if up to snuff. Maybe retroclouds can share some of his experiences in doing pitfall (which was released before my TI love was re-kindled, so I still need to buy that at some point as well)? Lessons learned, volumes that one can expect, cost of development, ...

     

    If we get this set up properly, the process should be easily repeatable for each new game and don't cause the developer to much headaches and overhead.

  5. Posted · Edited by TheMole

    if this is the bad apple demo it would be perfect for a port as it i black and white. Where can I find the loose frames ?

     

    Yup, that's the genesis version, which is definitely the best home console version. There's a NES and gameboy version out there as well, which are of course less impressive, but are cool as well.

     

    No idea where the raw frames can be gotten, but the developer is an active poster on the sega16 forum (his username is Stef), and has posted the sources of the mega drive version, so maybe you can find something useful there.

    http://www.sega-16.com/forum/showthread.php?19027-Bad-Apple-demo-thread

     

    By the way, this is a better version of the video. I probably would have had a geek teen orgasm if I saw this running on my mega drive back in the day...

    • Like 2

  6. Posted · Edited by TheMole

    Here's the code for the pattern data generation tool. I haven't done any clean-up on this, and the makefile only works on OSX, but it should be straightforward for anyone with knowledge of C and makefiles to compile this on Windows as well.

     

    It currently depends on SDL 2.0, so if you want to compile the code as-is, you'll need to have the developer libraries for that installed. I used it to import the bitmap and have a way of visualizing my progress. When this is in a more finished state I'll probably rip it out so it can be a real console program.

     

    To use it, just launch the app with a 16-color index bmp as the only argument. It'll show a double-sized 256*192 screen of the image, you can use the arrow keys to scroll in 4 directions on 8-pixels steps, and use the numpad + and - keys to change the current frame. Press escape to exit. At exit it will write a file called level.h that contains the patterns for the 8 frames, the color table and the map data in a 2D array.

     

    I will be updating this in the future, but I'm going on a business trip next week and don't know when I'll have time to work on this again, so I wanted to share what I had already.

    9918scroll.zip

  7. Posted

    PS

    this is a tech demo on youtube

     

    As I said before, this is an awesome demo. I've always wondered how you're doing the 3D scrolling though. I assume this is actually a pre-rendered animation? Would it be possible to use the same technique to show a 256*128 full motion video? If so, this could be a great way to port the famous bad apple demo to the MSX :).

  8. Posted

    Wow, what a polite post... I'm sure mizapf will be glad to help you now...

    I think if you knew what you were talking about you'd realize that MESS is the most accurate and complete TI emulator around, and merely because it doesn't come with a fancy UI doesn't mean that it sucks.

     

    A good honest RTFM is probably in order here: http://www.mess.org/mess/howto

     

    But to answer your question: press scroll_lock (or insert if you're using the SDL version, or delete if you're on a Mac) to put MESS in partial keyboard emulation mode and then simply press escape.

     

    But for your skillset it might also be good to look at one of the many excellent MESS frontends around. I hear QMC2 and My Arcade are pretty good.

    • Like 3

  10. Posted

     

    You are using 8 pattern tables located all over VDP RAM. I'm only using the first 8K for pattern tables, so I have to split each table into two. This means I either need two maps (one for frame 0-3 and another for frames 4-7) or I need to set the msb of each the byte I copy in frames 4-7. In the demo I'm only using one map, so frames 4-7 take about 18000 clock cycles.

     

    I guess your technique is better if you are able to fit your sprites patterns into the top half of a 2K segment.

     

    BTW, I never had time to follow all the steps in setting up gcc on my own computer, is it possible to zip an installation and copy it over?

     

    No problem. Mac, Windows or Linux?

     

    As for VRAM consumption, I think the SGT might be a problem or I'll have to be very smart about how I organize the sprite animations. My player character alone consists of 4 2x2 sprites (to get two color sprites of 32 pixels high), and 7 stances (standing, walking (3 animation frames), jumping, ducking and punching) in two directions (facing left and right). So if there were no duplication in the patterns that'd be 112 patterns (out of a maximum of 128 for the upper half of the table) for each direction. Enemies are typically 2 2x2 sprites, with two animation frames and two directions, so each enemy takes a theoretical maximum of 16 patterns. You'd need at least three enemy types per level, so worst case scenario I'd need to be able to store 320 patterns. In my VRAM map, there's room for 5 tables, but the animations for the different on-screen characters will need to line up nicely. I think that'll require another tool to prepare the data efficiently...

     

    Splitting out the different animation frames in different SGT locations would be a good start (also minimizes the number of bytes I need to send to the VDP for each individual sprite update). Of course, that would mean that the enemy sprite animations cycles need to be synced for all on-screen enemies.

     

    Still lots of interesting challenges to overcome before I can turn this into the game I have in mind :).

  11. Posted

    I use a single level map where each entry represents a couple of adjacent 8x8 tiles in the PNG image I use as input: say N the number of couples and assume 8 offsets for the scrolling.

    My tool generates an intermediate table Nx8 that for each couple (byte on the level map) returns the VRAM tile number for each offset phase.

     

    I think I understand what you're doing, and the concept is pretty neat! Depending on the level design there's often a lot of repeating patterns even within a single pair of tiles (look at some of my "grass" tiles, there's only 2 variants for the 8 scroll positions). I imagine you can save quite a bit there.

     

    But a couple of things are still unclear to me. Like, your VRAM memory map layout. And do you simply upload the entire nametable during vblank, or do you only update the bytes that have a different resolution in the Nx8 table?

     

    Also, wouldn't mind having a look at the tool you have.

  12. Posted · Edited by TheMole

     

    I will check what I get from pure assembler. It all boils down to the speed of updating the name/screen image table since all the patterns are pre-loaded. I think you're scrolling one pixel at a time, i.e. do you update 3 rows per frame, right?

     

    Indeed, per-pixel. The following block of code copies the three rows from the map array, which is a 2D array organized per row (that way, you can bulk-copy 32 bytes per loop).

    vdpmemcpy((backbuffer_sit * 0x400) + (row * 32), &(map[row][col]), 32); 	row++;
vdpmemcpy((backbuffer_sit * 0x400) + (row * 32), &(map[row][col]), 32); 	row++;
vdpmemcpy((backbuffer_sit * 0x400) + (row * 32), &(map[row][col]), 32);

    The vdpmemcpy function comes from Tursi's lib, but it's so simple it probably compiles to the most efficient assembly already:

    void vdpmemcpy(int pAddr, const unsigned char *pSrc, int cnt) {
	VDP_SET_ADDRESS_WRITE(pAddr);
	while (cnt--) {
		VDPWD=*(pSrc++);
	}
}

    I can of course win some cycles by inlining the function, or replacing it by a macro to avoid the context switch overhead.

    All-in-all, the code is so simple I'd be surprised if there's a huge speed difference once the obvious optimizations are done.

  13. Posted

    If all goes well that should be very soon, I need to clean it up a little (add proper getopt support and put some safeguard tests in there to ensure it doesn't crash) and make sure it compiles on windows, but that shouldn't take long. Hopefully I'll find a couple of hours this week-end. Should also be useful for the MSX and (memory permitting) Colecovision folks.

  14. Posted · Edited by TheMole

    Ah, ok. Took me a while to find the scroll lock key on my laptop (had to find an external keyboard actually...).

     

    It's a bit of a hassle figuring out where the while loop starts and ends, but if I instrumented the code correctly it seems that one iteration of the main while loop (without scanning for keys or vsync so free-running only automatic scrolling from left to right) takes on average 15000 cycles, or 0.005 seconds, which puts the framerate at around 200fps (which is close enough to my hand-timed number to make me believe I've used accurate breakpoints). I'd be curious to know how many cycles it takes with hand written assembly code.

  15. Posted

    Did I do what with the what now? :)

    Actually, I didn't know there was such a function. I can't seem to get it to work though. The loop for 8 frames starts at >CBCC and ends at >A2A6, so I would suspect adding a 'breakpoint' with T(CBCC-A2A6) would do the trick, but I see no output in the debug window... I'm probably just doing it wrong.

  16. Posted

    True, I justed wanted to see how fast it could run without waiting for vsync. That's a thousand frame in slightly under 6 seconds, so 175fps or so. Plenty of room for game logic. Tursi's lib makes it as simple as one call to add vsync though, so when I turn this into a game it'll definitely be there.

    I recorded a video (no vsync) on my mac, through mess. It still looks a lot smoother on screen than in the recording, and the colors don't do well with the youtube compression, but a video is always a bit nicer for people to look at, so here goes:

     

    http://www.youtube.com/watch?v=QnlgHKpqH6o

    • Like 2

  17. Posted

    After seeing Rasmus's great work, I decided I wanted to start working on my own smooth scrolling games for our beloved TI. Initially, I was set on using the F18A for the scrolling functionality, but alas... since I don't have a hardware setup right now and no current emulator supports the thing's scrolling registers I'm stuck with the good ol' tms9918a (for now).

     

    Since I'm lazy by nature and I didn't feel like programming a whole game in assembly, I couldn't use Rasmus' excellent scrolling example code and had to re-implement it in C. I also didn't want to spend too much time transforming the assembly output from Magellan into something directly usable from C. I looked at adding a C exporter to Magellan, but the export .java source file alone was so daunting I decided to write my own tool to generate the scrolling patterns. Since I prefer to work in The Gimp to create the level, I wrote a simple command line program that takes a 16-color bitmap file that represents the scrolling map and generates a C header file with the pattern, color and nametable data (graphics mode only, for now). Maybe I'll look at turning this into a Gimp export filter at some point.

     

    For those that are interested, the simplest horizontal scrolling C application that uses the exported header file is only 100 lines of code and looks something like this:

    // Includes
#include "libti99/vdp.h"  	// Tursi's libti99, VDP functions
#include "tistdio.h"		// Quick set of functions for keyboard scanning
#include "level.h"		// Generated header file containing map data

#define SIT1	0x01
#define SIT2	0x03
#define CT	0xFF

// copy 8 pattern tables into VDP RAM
void init_patterntables()
{
	int frame = 0;
	
	// Write 8 pattern tables to VDP memory
	vdpmemcpy(0x800 * frame, patt_frame0, 768); frame++;
	vdpmemcpy(0x800 * frame, patt_frame1, 768); frame++;
	vdpmemcpy(0x800 * frame, patt_frame2, 768); frame++;
	vdpmemcpy(0x800 * frame, patt_frame3, 768); frame++;
	vdpmemcpy(0x800 * frame, patt_frame4, 768); frame++;
	vdpmemcpy(0x800 * frame, patt_frame5, 768); frame++;
	vdpmemcpy(0x800 * frame, patt_frame6, 768); frame++;
	vdpmemcpy(0x800 * frame, patt_frame7, 768);
}

// Copy colortable to VDP RAM
void init_colortable()
{
	// Init the first two black, the third one gray
	vdpmemcpy((CT * 0x40), colortable, 13);
}

void init_nametable()
{
	int x, y;
	
	for (x = 0; x < 32; x++)
		for (y = 0; y < 24; y++)
			vdpmemcpy((SIT1 * 0x400) + (x + (y * 32)), &(map[y][x]), 1);
}

void copy_pattern_block(int col, int frame, int backbuffer_sit)
{
	int row = frame * 3;

	col++;
	vdpmemcpy((backbuffer_sit * 0x400) + (row * 32), &(map[row][col]), 32); 	row++;
	vdpmemcpy((backbuffer_sit * 0x400) + (row * 32), &(map[row][col]), 32); 	row++;
	vdpmemcpy((backbuffer_sit * 0x400) + (row * 32), &(map[row][col]), 32);
}

int main(int argc, char *argv[])
{
	int x, prev_x;
	int frame, backbuffer_sit;
	
	// Init graphics system
	x = set_graphics(1);
	VDP_SET_REGISTER(VDP_REG_MODE1, x);
	VDP_SET_REGISTER(VDP_REG_PDT, 0);	
	VDP_SET_REGISTER(VDP_REG_CT, CT);	
	VDP_SET_REGISTER(VDP_REG_SIT, SIT1);
	VDP_SET_REGISTER(VDP_REG_COL, 0xF1);
	init_patterntables();
	init_colortable();
	init_nametable();

	prev_x = x = 0;
	backbuffer_sit = SIT2;
	while(1)
	{
		// Scan keys and do movement
		// scan_keys();

		// UP/'E' pressed, move forward
		if (check_key(2,0x4000)) 
			x++;

		frame = (x) % 8;
		if (x != prev_x)
		{
			// Move backbuffer to front and vice-versa
			if (frame == 0)
			{
				VDP_SET_REGISTER(VDP_REG_SIT, backbuffer_sit);
				backbuffer_sit = (backbuffer_sit == SIT1) ? SIT2 : SIT1;
			}

			// Advanced frame 1 pixel (aka move pattern descriptor table pointer one position up)
			VDP_SET_REGISTER(VDP_REG_PDT, frame);	

			// Write 3 rows of the next full frame to the backbuffer
			// Depending on frame this is either 0-2 (frame 0), 3-5 (frame 1), 6-8 (frame 2), ...
			copy_pattern_block(x >> 3, frame, backbuffer_sit);
			
			if (x > 1016)
				x = 0;

			prev_x = x;
		}
	}

        return 0;
}

    Project files, FIAD file and disk image attached for those who want to see it in action (EA#5, ALEXKIDD). The generated code is in level.h and is untouched, what you see is what the tool generated. I tried making a video, but the result looked anything but smooth. If you want to run it in an emulator, I suggest MESS as Classic99's timing is a bit off and makes it look a bit jittery. As you'll see, it runs quite fast as-is, but I'm sure there's room for improvement as this is completely unoptimized code.

     

    I'll make the tool available soon as well, but I need to clean it up a bit before it's fit for public consumption. I also need to add a binary file export function, 'cause the C header files are actually way too memory hungry for any practical use. In the future I hope to also add up-down and bitmap mode export functionality. Currently it just does what I needed it to do, and that's it.

     

    csmoothscrolling.zip

    • Like 2

  18. Posted

    so it was already released? too bad then :(

     

    Wait, what? I've never seen it available on the colectorvision site, and even today it's still listed in the "upcoming games" section... How come we never heard of this being released?

    • Like 1

  19. Posted

    First, let me state that this is such an awesome game, I actually played this for fun for over half an hour today and that's quite the achievement for a retro game outside of my favorite genre (platformer). This is top class stuff, and I don't care that I've said it before 'cause it bears repeating! Kudo's, of the three Rasmus games, this is by far my favorite.

     

    I can, however, echo the two bugs described by Kurt below. The first one is very minor as it's just a few small graphical glitches, but I've been bitten by the second one as well and that one is slightly more annoying :).

    - Sometimes, strange objects come down the road. One type of strange objects is debris from a seemingly crashed car which already comes down as debris. Then there are cars standing sideways, but they still seem to move up the road which is physically impossible.
    - Sometimes the finish line doesn't get recognized. This happened to me multiple times, usually if you crash just before hitting the finish line. On one occasion I had to drive through the whole track again, then the finish line was recognized. On another occasion, I had nearly completed the snow track, but just before the finish line there was an oil slick which I drove straight into, causing the car to spin and crash into the roadside. Then it was game over because I had lost all cars, but I had clearly crossed the finish line before I crashed, which wasn't recognized.

  20. Posted

    The game is about earning points by bumping or shooting the other cars off the road, while avoiding crashing and running out of fuel. The demo allows you to play a full level/track more or less as I imagine the finished game. There are still some tiles left for improving the graphics, and the current music score (borrowed from Spy Hunter) will need to be expanded or it will drive you mad after a while. I'm also planning more levels, of course, and perhaps other items on the road to pick up or avoid.

     

    Excellent work. Very impressive scrolling and arcade-like response times. It is great to see such responsive, smooth and playable arcade games on the TI. And with background music!

     

    I would however like to make a gameplay suggestion that might be a bit removed from what you have in mind... take it for what it's worth, it's just an idea :).

    What if, instead of making the game about scoring as many points as possible and hoping you capture enough fuel barrels to reach the end of the level, you turn it into something a bit like a top-down version of Chase HQ:

    • The goal of each level is not to reach the end, but instead to catch up to a run-away car that you need to destroy at the end of the level.
    • Instead of crashing into cars to score more points, you could make it so you have a "health bar" and you need to avoid getting hit too many times to ensure you are still in good enough shape to battle the car you're chasing. You can battle the bad guy by bumping into him, driving him into the side of the road or shooting him. He also has a health bar that you need to deplete to finish the level.
    • You lose the game either by letting the bad guy get too far ahead of you, or by destroying your car.
    • Along the way you can pick up repair items and bullets (not sure if fuel would be needed as a gameplay mechanic in this case).
    • You'd probably need to get rid of the one-hit kills be crashing into the side of the road (maybe that could do double damage instead).

    I know it's quite different from what you have in mind, and I'm just putting it out there, but it would make the goal of the game a bit more enticing to me. The "high score" type gameplay isn't my cup of tea in general and I always loved Chase HQ :).

  21. Posted

    Looking at the docs this looks like it's an interpreter as well as a compiler (or maybe even some sort of JIT compiler), which is pretty cool. It also seems to be possible to save programs in object format (it even looks like that's the default). However, looking at the feature set and how it maps onto TI BASIC, I'm not sure it's worth hacking it to run on a TI. Writing a source compatible ANSI BASIC interpreter is not that hard, and will probably be a lot easier than trying to hack this into a bank-switched, VDP memory raping monster.

    • Like 2

  24. Posted

    Have you tried doing simple RLE comperssion on the data to see how much that gains? Probably not enough, but it would be my first try if I were to develop something like this from scratch.

     

    Secondly and more likely, they probably have some kind of meta-tile system in place (my guess would be somewhere around 8x8 patterns in size). Pretty much what sometimes99er is saying for the "besides the road" type stuff in his example.

     

    Last idea: there might be some repeating sections in each of the maps?

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...