Asmusr

It's possible, but the graphics would have to be very simple. Try to make a mock-up of your map in Magellan and we can discuss how to scroll it...

Here is the source code ('Horizontal graphics scroll.a99') to produce a smooth scrolling version of your map. I intend to include the source with Magellan at some point, which explains the formal comments at the beginning, but you're welcome to remove all that. A disk image with an assembled version is also included. Load and Run E/A#3 DSK1.HGSCRLC. You can change scrolling direction (left/right) using the joystick. Note that it is possible to move outside of the map if you insist. When exporting from Magellan, don't include character numbers. This will mess up the display since the numbers will be treated as pattern data. You don't need to generate scrolled character frames either (although I have included them here). My code (HSCRL routine) will scroll the patterns for you while they are uploaded to VDP RAM, and leaving the scrolled patterns out will save a lot of CPU RAM. For demonstration I have included another routine (CPYPAT) that simply copies the scrolled patterns generated by Magellan to VDP RAM. You can try that if you like, but for future work I suggest to use the HSCRL routine and exclude the scrolled patterns from the Magellan export. I don't know how important performance is for you? This demo is using up to about 40% of a 60Hz screen update cycle. It's the same algorithm I used for TI Scramble. It could be made somewhat more efficient by moving central copying loops (VMLW, VMLWH) into scratch pad. And if you have enough RAM to spare you can make two copies of you map (one with the most significant bit set) and reduce it to use only about 20% of a cycle by eliminating the slow VMLWH. The source code is not that well documented, so please ask any number of questions you like. HorizontalScroll.zip

Thanks, I will look at them tonight. Just to clarify that the assembler output from Magellan is just the data (map, color table, scrolled patterns). You also need an assembler program to perform the scrolling. This can be programmed on a PC (look in the "TI-99/4A development resources" thread for tools), or if you have lots of patience, directly on the TI.

What happens if you try to do it anyway? Is VSP just ignored when VSIZE is zero? Another question: is Graphics Mode 1 (with or without ECM) the only mode where scrolling works? How about half bitmap mode?

Great to see a new game project. I will do my best to help. I see that you have made 4 individual 32x24 screens in Magellan instead of one 128x24 map. The latter would be a better starting point for smooth scrolling. There are only 48 horizontal character transitions in your map, which is good. If you go above 128 you will be limited to 2 pixels scrolling (assuming that you want to keep all scrolled patterns in VDP RAM, which I would highly recommend.) I will be happy to put together a modified version of one of my demos for you that can scroll your map right or left. Just give me a few days...

Hi Matthew, In a vertical scrolling setup on the F18A, is there 1K or 2K between the two name table pages? This post http://atariage.com/forums/topic/168968-f18a/page-27?do=findComment&comment=2573661 states that there is 1K between them, but this post http://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/page-5?do=findComment&comment=2848296 says "that the VSP will select between 0 (0K) or 2048 (2K) offset". In case of the latter, is it possible to use the VSP in a horizontal setup to choose between displaying/scrolling pages 1/2 vs. pages 3/4? The reason for these questions is that I'm thinking of the best way to implement smooth scrolling on the F18A that will fall back nicely to character (8 pixels) scrolling on the 9918A. For that I think you need some kind of double buffering scheme. So after scrolling 8 pixels on the F18A using the scroll registers you switch to another name table that is offset by one character, reset the scroll register, and repeat. The idea is that the 9918A will ignore the scroll registers but will respond to the name table switching, so it will scroll in character offsets using the same code that on the F18A produces smooth scrolling. Does that make sense?

Thank you, much appreciated.

If you hit fill by mistake, which I have also done many times, there is now an undo button in the upper left corner. But the fill functions should also have a confirmation dialog.

A good idea that I might consider for the next major version.

I fixed a few bugs, and added support for transparency in ECM. So here is version 2.0 in 3 different editions (Windows 32, Windows 64, cross platform). Magellan V2.0 ------------------ * Import Map Image * Copy and Paste buttons for easy copying of characters * Color mode check when opening files * ECM screen colors and transparency * Shifting of character patterns is now cyclic * For various Export options the Setting dialog is now shown before the Save As dialog * Windows installer Season's greetings from Denmark. Magellan_windows_2_0.zip Magellan_windows-x64_2_0.zip magellan-2.0.zip

I can either bundle a JRE with the 32-bit version or make another 64-bit version. I guess the latter will be the most useful solution. Try the attached. You may want to uninstall the 32-bit version first if you still have it installed. Magellan_windows-x64_2_0_beta.zip

The colors in your test image are imported fine in ECM 2 or 3, but there are 1715 unique 8x8 characters in the image, and I'm not trying to handle characters beyond 255. So a large part of the map is filled with the last character. A more sophisticated algorithm could do a best match to one of the characters 0-255 instead of just choosing the last one.

The main change in this beta version is the addition of a map image import function that allows you to import an image of any size with less than 256 unique 8x8 tiles. This is really useful if you want to rip graphics from MAME, SMS Power or other sources. When I started implementing this function I soon realized that an algorithm that produces an optimal color conversion could be extremely complex - especially in the F18A Enhanced Color Modes where there are so many parameters to adjust. The algorithm in the beta version produces a reasonable result in all color modes, but works best if the source image is not too far from the capabilities of the target color mode. Map files saved from now on will include information about the color mode. If you open a file saved in another color mode than the current, Magellan will ask if you want to change the color mode. Other changes include the addition of The Mole's graphics, and a proper Windows installer. The latter will register .mag files to open with Magellan. It still requires Java to be installed. The preferences file is now saved in the user's home directory, so when you run this version of Magellan for the first time all options will have been reset. The second, smallest, attachment is the usual cross platform version. Magellan_windows_2_0_beta.zip magellan-2.0b.zip

I would like to add sprite support at some point, but it seems like a lot of work. Do you think sprite overlays could be added without a full featured sprite editor?

Thanks, I really like the idea of the map turning into tiles, but it's very detailed for an icon, and in resolutions below 64x64 it's not recognizable. The splash screen I can use as it is, but do have an idea for a less detailed icon that would work in lower resolutions? I'm planning to release the next version as a 'native' Windows program with installer and exe file built using install4j. I can also build Mac or Linux versions if there's any interest.

Would anyone like to draw a nice logo/icon for Magellan?

I just realized how great a resource smspower is for ripping graphics for the TI. I will definitely add a map importing function to the next update of Magellan.

Magellan could really benefit from improved import functions. The existing Import Character Image function expects a 64*256 bitmap with unique characters (no map). I have added the Magellan file to my original post if you want to see how it looks. Regarding the use a masking sprite, the tiles can have as many as 32 different colors within a 16x16 area, so you would need to plan the colors carefully or use several 8x8 masking sprites. I don't know if that's easier than changing the base sprite pattern - perhaps the invisible part could be changed to an outline as you suggest? The problem using the tile priority is that it affects all instances of a tile on the screen, and also that the 'background layer' of each tile would be limited to one (transparent) color through which the sprites are visible. There are many places where tile priorities would be really useful, e.g. drawing the bridge that you walk under in a Commando clone, but I think the model may be too simple for an isometric game. Another option for an isometric game would be to use the bitmap layer and software sprites. Much less colorful but, but it would allow you to draw real isometric tiles in back to front order. The GPU could easily handle this. I'm not sure if I'm going to do any of this. I'm still looking for the really good idea for my next game...

The question is how to move sprites behind the trees, building etc. I know you can specify that a tile has priority over sprites, but I'm not sure that will be enough. I think you will have to change the sprite patterns dynamically based on the position, the tile map, and a depth map. Any good ideas?

A demo of isometric graphics made using tiles in ECM3 (8 color) mode. The graphics were created in Magellan. I found the pretty trees on the net. If you run E/A#3 ECM3C from the disk, the screen will be scrolling, this time using the F18A scroll registers. Edit: added Magellan file to the zip. ECM3Scroll.zip

I'm using a very cheap Chinese programmer TOP853 (search on ebay). It works fine and supports lots of EPROMs but I didn't manage to install the USB driver under 64 bit Windows, so it's running on an old XP installation. I think their latest models have 64 bit drivers.

Thank you for the code. I didn't know how the algorithm worked, e.g. that you only cast one ray for each column. I made a VDP RAM dump of a typical screen and imported it into Magellan. I only counted around 25 unique patterns in the first pattern table, and if this is the general case that a small set of patterns is used over and over, I guess you could do this a good deal more efficiently by updating the name table instead of the pattern tables. Any thoughts?

The demo is actually using 3 buffers: the original image and two display buffers. Each one is 4K so there is still room for name table, pattern table, color table and the program. With more optimization, e.g. incremental calculation of the source address, I think you could double the frame rate.

In this demo my mushroom logo is taking the F18A for a spin. http://www.youtube.com/watch?v=ly0QLST4nl4 Source code and E/A#3 file attached. Only works on the hardware. ImageRotate.zip

Is there any way to use the PIX instruction on an off screen bitmap buffer? I know you can use it to calculate the address only, and you can then adjust the base address to point to your buffer, but that hardly saves any code (calculating the address is just two shifts and one add anyway). It would be really useful to be to be able to draw to a buffer that's not currently visible and then change the bitmap layer base address to point to your buffer once the drawing is done.