TheMole
-
Content Count
855 -
Joined
-
Last visited
Posts posted by TheMole
-
-
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.
Yeah, it's difficult to keep the same concept at very low resolutions. I tried a slight variation on it that should hopefully hold up better at lower resolutions, but I'm not sure if it's better. What kind of resolution are you looking for actually?
I'd want both a Mac and Linux version, I try to minimize my Windows time
.Also, since I'm making requests anyway: have you ever considered a C .h file style export function? That would be applicable to all TMS9918a/F18A sporting platforms in a kind-of platform independent way and might lead to more traction for the tool in other communities as well. Plus, I'm a C junkie, so it'd be perfect for li'l ol' me
-
1
-
-
I'm not a graphical expert by any stretch of the imagination, but maybe the attached is useful?
-
3
-
-
The ZX Spectrum doesn't have a tile-based VDP, so the techniques applied there are difficult or impossible to use on the TI. Most of what you see on the system is probably pure "software rendering", which means that you easily achieve this by blitting in three phases: first all "background" tiles, then the "sprites" then the "foreground tiles".
As for that video of Hydlide 3, that's f*#kin' impressive! The graphics are very well designed, and I would've killed (well, not really...) to have something like that on the TI back in the day. Looking at it, my guess would be that they change patterns of the sprite depending on the foreground. The characters are obviously sprites since they flicker when 3 or more are on the same scanline, but they move in 8-pixel increments which would help reduce the number of patterns required to display the "behind stuff" versions of the sprite (since each foreground object has a different mask for the sprite). There's too many colors for the foreground to be masked with sprites, so it must be done using patterns. They might be doing this in real time by XOR-ing the tile-pattern definition with the sprite-pattern definition. This is only four XOR instructions in bitmap mode, but would be 12 in ECM3 3bpp mode. Then again, it could easily be done on the GPU and maybe that's the best answer to Rasmus' question:
- Keep a "source" copy of all sprite patterns somewhere in VRAM
- Every frame, for every sprite check whether it is in front or behind the current tiles it occupies (using a depth map, for instance).
- For every tile that is potentially in front of the sprite, there is a mask definition (basically a 1bpp tile pattern that distinguishes between foreground and background pixels).
- XOR this mask pattern with the sprite pattern into a new location that will be used by the actual sprite definition. Of course, if you want your sprites to move with pixel resolution you'll need to do some bit twiddling first to align the mask definition with the position of the sprite, but I image the GPU could do this with ease during VBLANK
But man, those are some nice 9918a graphics!
-
Been looking at Scarabeus for the C64, it was released in 1985 and as far as I can remember was the first sort of 3d game of its type, wonder what technique it used for it's 3d?
My guess would be they are using pre-calculated animations in this one (seeing how the player is always smack-dab in the middle of the corridor, always stops exactly at intersections and always turns in 90° increments). But given how many pixels change on screen every frame I'd say that this is unfortunately going to be a little bit too difficult for our little TI to pull off. The C64 CPU has direct access to VDP memory and that makes a huge difference in terms of how many updates you can push to the screen.
-
Is the plan for you to develop this into a full game?
You know, I never had a game in mind when I started this, just wanted to see if it could be done. If anyone has a good idea for a game, I wouldn't mind taking a stab at it though.
Biggest problem is that with the current horizontal resolution it's near impossible to include objects in the engine, so I'd need to fix that first.
-
Rasmus' post got me thinking. I wasn't really correct when I said you'd need over 500 different patterns to pull this of by just changing the name table in graphics mode instead of the color table in bitmap mode. In bitmap mode, we effectively have pseudo-pixels that are made up of 4x2 hardware pixels, which means that all permutations are made with only 50 patterns. Unfortunately, you need these patterns twice in order to do shaded walls, resulting in 100 patterns for walls that can only come in one color (but two shades of that color). So in theory you could do two differently colored walls with 200 patterns and still only update the name table. Problem would then be color clashing artifacts when a slice changes color mid-pattern, but it would be possible.
So I wondered how it would look if I changed the pseudo-pixels to a size of 8x2 (losing half of my horizontal resolution, but keeping the vertical resolution). That way you only need 8 patterns per shade (although unfortunately they need to be split out on two color table entries in order to have different colors for the floor and ceiling).
The result runs much faster as you can see in this video (classic99 without overdrive), but in my humble opinion at times gets too ugly to be useful (especially when you're close to a wall on your side, look at the lower part of the left-hand side wall in the youtube thumbnail below or when I try to go through the blue doorway in the video):
http://www.youtube.com/watch?v=bCY0wM2U788
I also added collision detection (but not wall sliding physics, so it doesn't feel very nice yet... at least you can't walk out of the map anymore
)TIFILES version attached, let me know if someone wants to see the source code, the main raycasting function is exactly the same, but the draw_slice function is now all in C, and the blitting to the VDP is now just a single vdpmemcpy command from Tursi's lib.
-
7
-
-
Neat graphics, would love to see this in action but don't have the F18A installed yet...
You could have a masking sprite per character sprite. The masking sprite would have a higher sprite number than the character sprite and follow the character sprite (although only moving in 8-pixel steps, so always on image pattern boundaries) and you'd have to load the patterns of the underlying background into the masking sprite's definition each time, but it should be doable. You might also need to have different patterns that have a transparent background if your image patterns use all 8 colors. Still easier than dynamically changing the sprite patterns I think.
All that said, I find nothing more frustrating if a character is truly hidden from view in a game and my real answer would probably be to let descent map design solve this for you. . If you don't want to hide the sprite but instead give the impression it is behind an object, you could consider one of the following cheap tricks:
- Flicker the character sprite whenever at least a portion of the sprite is supposed to be behind a background, making it appear somewhat translucent.
- Change the sprite definition to something that indicates the sprite is behind the current background image (which I suppose would then technically need to be called the foreground image), such as an outline of the character instead of a full colored-in version.
I tried loading the png into Magellan, but the colors become messed up and the map is truncated to the screen. Is there another way to load images into Magellan and let it turn it into character definitions, palette definitions and a scrollable map? It'd be great if one could load one of these and spit out map data: http://www.smspower.org/Maps/AlexKiddInMiracleWorld-SMS?gallerypage=The+City+of+Radaxian
-
It shouldn't be that hard to leverage the F18A. The most logical first step would be to run the draw_slice function on the GPU instead of the main CPU and that piece of code already is 9900 assembly in the current code. I could imagine simply uploading the calculated sliceheight and color for every ray, setting a pointer to this table at the end of the raycasting function and letting the GPU actually render the slices. This would not only save the CPU the trouble of calculating the color table, but would reduce the number of bytes to upload to the VDP every frame from 2048 to 128. Just that alone will lead to a very sizable improvement in framerate, but the TI would still be the one doing the actual raycasting (which in my mind makes it less "cheating"
).An added improvement would be to have the GPU render the slices texture mapped instead of using a flat color. Something close to a "real" wolfenstein lookalike (except for the resolution) should be perfectly doable.
But... I don't have my hardware setup, and my F18A is still safely tucked away in a drawer and it doesn't look like that'll change in the next couple of months. So I'm stuck with emulation, which means no real way to develop F18A programs for me...
-
Yeah, the raycasting part is a fairly lean algorithm and is relatively cheap to do on the 9900, it's the blitting from RAM to VRAM that takes by far most of the cycles currently.
But contrary to what you would intuitively think, I don't upload new patterns every frame. In fact, all patterns in the first two pattern tables are initialized to "0F0F0F0F0F0F0F0F" at the start of the program and they stay that way while the program is running. The first two nametables are initialized with 0 - 255 (so every position in every nametable points to a unique entry in the pattern table). The actual drawing is done by fiddling with the color tables. Since we're in bitmap mode, every 8 pixels can have two colors. By defining every pattern as "0F" we basically split every 8-pixel column in two pseudo-pixels: the odd pseudo-pixels are set by changing the background color in the color table entry for that pattern, the even pseudo-pixels by setting the foreground color. This gives us a horizontal resolution of 64 pseudo pixels. Since we only use the first two nametables, we have a maximum vertical resolution of 128 pixels, which we divide in two again by using the fake scanline effect. This gives an effective resolution of 64x64 pixels and since every byte in the color table defines two pseudo-pixels, we "only" need to upload (64x64)/2 = 2048 bytes to the VDP every frame.
So that's how it works today, since that gives us something which is all things considered relatively close to a flat framebuffer. Your idea sounds intriguing, 'cause the name tables are of course only 512 bytes. But in order to really make it more efficient you'd need to move to graphics mode instead of bitmap mode 'cause in bitmap mode you'd have to upload the color tables as well which are always going to be 2k (if rendering using scanlines, otherwise it's 4k). In graphics mode the color table is only 32 bytes, but we are going to run into color clashes (where a wall meets the ceiling and another wall everytime it's not on an 8x8 character boundary) so we'd have to work around that somehow and I'm not really sure if that would look nice (might make movement look a lot more choppy since you'll be forcing the transitions per character block). Then there's the question of how many patterns you need to model every theoretical wall slope. Trying to figure this out of the top of my head I would say that you can have 15 different slopes in 64 positions in a single pattern, so 960 different patterns (this definitely includes some duplicates, so it's maybe half of that), which is of course too much, especially if you want to support more than one color of wall.
All that said however, this is definitely the area in which optimizations are to be found. It's by far the most taxing part of the algorithm.
I have also been thinking about changing the type of raycasting I'm doing, moving to some form of hybrid raycasting/2D portal engine. The current algorithm is based on how Wolfenstein does it: the world is defined simply by putting cubes on a grid (the worldmap variable). I could instead define a world made up of rooms defined by 2D line segments (like a floor plan). Instead of checking against every square border in the map for every ray and testing whether or not the square is occupied by a wall (which is very much an iterative process: every frame almost 1000 inner loops are run before the 64 rays are cast), you'd check for an intersection of the ray with each of the line segments that make up the room, take anywhere between 4 to 10 line segments (aka walls) per room on average and it's clear that you'll need a lot less iterations. Finding the intersection point between a ray and a line segment is a more difficult calculation but you'd need to do a let less of them. On top of that, it's easy to optimize finding the right line segment by simply ordering them in clockwise fashion and starting from the same line segment you found an intersection with during the last ray. That way either your first or in worst case scenario second line segment will be the right one so your average number of intersection tests per ray will be between one and two.
The major limitation would be that the rooms need to be convex to avoid having your ray intersect with more than one wall per room, but apart from that there's three major benefits to this approach, I think:
- You can do more than just a grid of blocks and walls can meet at other angles than just 90°
- Storing your rooms will take less RAM than the current approach
- It should be faster than the current approach.
You'd need to do something clever to render through doorways however. That's where the portal engine ideas come in (the Unreal engine was the first famous portal engine, but that was of course a full 3D polygon renderer): a door is simply a special type of wall, called a "portal" that links one room to another. If your ray intersects with a line segment that represents a portal, instead of simply taking that distance and rendering your slice using that the engine will need to start testing against the line segments in the adjoining room as well. This runs the risk of becoming a recursive problem, but being a little careful with your level design should be enough to make sure that never happens.
Wow, I'm rambling... sorry about that, I'll shut up now
-
1
-
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.
Tres cool! For some reason I immediately imagine a spinning/scaling batman logo and accompanying jingle...
-
Source attached. You're going to need gcc to compile this but once you've got the environment installed it should be easy to build. Just edit the Makefile to reflect to your compiler's path and where you want to the TIFILES to be installed, issue "make install" from the command line and you should be good to go. I included Tursi's libti99 (binary and headers only), 'cause you need that to build, but if you stick to the directory structure as in the zip file you should be good. The cart version doesn't work (too large, so it wraps onto itself and the world map is messed up), so use the EA#5 version.
I haven't spent much time cleaning up the code, so all the important bits are still in one file (wolfie3.c). Other than that, it should be quite self explanatory. The one tricky part in the code (to me at least) is the draw_slice assembly code, which is compiled but copied into scratchpad memory for speed and that requires some extra trickery that might look strange at first.
-
It might not look like much, but I'm proud to finally present the first test version of my raycaster that finally looks somewhat like it's casting rays (if you squint really hard)! Huge thanks to Tursi for helping me debug this and for the assembler version of the algorithm to render the wall slices. As it stands the engine is still way too slow to be usable, and I'm not sure this algorithm is the best way to go, but it's a start and a relatively good way to evaluate the rendering format. Ignore the random gaps between walls and the unwanted dark stripes on some of the walls. These are basically rounding errors in the casting routines that still need to be ironed out.
For those that want to try it out I've attached the program in FIAD format, just unzip and drop WOLFIE3D into a DSKx directory or dump it on a disk image (depending on your emulator of choice), and run WOLFIE3D from EA#5. Use the arrow keys to walk around and know that there's no collision detection so you'll walk straight through the walls (and if you move to far out of the map you're likely to crash the program). I can recommend using Classic99's overdrive mode, or MESS's throttle mode to speed things up a bit (although it can become twitchy on really fast systems then).
I've made a quick video as well, for those that don't want to download. I turn on CPU overdrive about halfway throught the video so you have an idea of how it runs with and without.
http://www.youtube.com/watch?v=OIG33UBHDG8
I'll clean up the source code and post it for those that are interested when I get some time. Just wanted to get this out there...
-
9
-
-
Why don't you just use MESS in Linux? Especially on Ubuntu it's dead easy to install: simply do a "sudo apt-get install mess", copy the roms to the right folders and you're good to go...
I know it doesn't have the paste function, but it has other elegant ways of quickly getting XB programs in memory.
-
Thanks for making the video Rich, it'd be great if you could do one for YAPP as well if you find the time.
As for the color issues, what I think is happening is that MESS (and/or the EVPC in real life) don't support the second data port for changing the palette registers. As you know, the v9938 is not pin-compatible with the tms9918a and you need to solder an additional address line from the CPU's address bus to the VDP. This creates a second port to communicate with the VDP and according to the v9938 manual the palette registers reside on that second port. So without soldering that extra wire there is no way that you can change the palette registers from their default state. It could be that MESS or even the real EVPC don't implement that second port and just make due with the standard palette. I've got a sneaking suspicion that the SGCPU combined with the EVPC could give the results you're expecting, but I don't know how to configure that in MESS as they seem to be two separate drivers.
Maybe Michael can chime in on the EVPC and it's implementation in MESS...
-
Download link: http://www.mizapf.de/ti99/fractals.dsk
I just took the time ... for the standard image (whole Mandelbrot set; -2.6 < x < 0.9, -1.25 < y < 1.25) the program runs 76 minutes, with a maximum of 100 iteration per pixel, 512 x 212 pixels on screen. The number format that the program uses allows for a resolution of 2^-48, which is 3.5*10^-15.
The MESS keyboard on the Mac is unpredictably difficult to understand. On the "select language" screen, how do I proceed (in English, if possible
)? -
I can upload a copy (disk image) here.
That'd be great, but I know so little of working with the Geneve that it would probably take me too long to get up and running. Is there a Geneve quick start guide for TI guys available somewhere?
-
As for VAPORWARE that is any software that does not exist but some one cites a example of how it could be faster on modern hardware compared to existing old hardware.
(Despite the new hardware does not have a single program that exists to do it!) VAPORWARE is musings with no evidence.
I would love to set up MESS but every attempt requires me to load something like Visual Studio which of course I do not have. Or load things that breaks other things.
Last attempt broke my BOOTCAMP drivers and made a mess that took me 3 days to fix.
Don't worry, I know what vaporware is Rich... I'm using the same definition as you.
Anyway, I've gone through the steps to set up MESS on my Windows work machine (Windows 7) and put together a zip file for you. It runs fine on my machine.
https://www.dropbox.com/s/be71yzc94e54ofx/mess.zip
If you download the above file and unzip it to a folder of your liking on your system you should have a fully functioning MESS install. It also includes the XHI and YAPP disks I mentioned above, as well as the extended basic and editor/assembler modules. In order to use it you will need to use the command line though, so be aware of that.
Suppose you've unzipped to folder to c:\mess then you can use the following commands to run XHi and YAPP respectively:
c:\mess\mess.exe ti99_4ev -skip_gameinfo -peb:slot8 hfdc -window -nomaximize -natural -cart carts/extended_basic.rpk -flop1 disks/XHI.dsk
c:\mess\mess.exe ti99_4ev -skip_gameinfo -peb:slot8 hfdc -window -nomaximize -natural -cart carts/editor_assembler.rpk -flop1 disks/YAPP.dsk
To run YAPP, you go to E/A option #5 and load DSK1.YAPP
Let me know if you need any further help with this.
-
1
-
-
TAKING ANOTHER TACK
Just jumping in with another reason to have the expanded Vram available - Programming.
Fire up Funnelweb configured for 80 columns and 128k buffer.
Load the file SOURCE from the disk image attached to this message. It's about 60k.
I like to be able to view the entire source of a program, rather than the time consuming process of loading shorter segments to find the part I'm looking for, and Funnelweb allows me to do this. Saves a lot of time for me and makes the process infinitely easier. If I had to go back to a 16k buffer I'd probably discontinue my programming efforts, too much of a hardship.
Gazoo
Yes, absolutely. FunnelWeb makes good use of the memory to achieve something that could otherwise not be done on a stock TI+32k.
But can the same thing not be achieved using the SAMS (or AMS) instead? Load the entire file in the SAMS and only push the visible pages to the VDP? Because like I said before, I'm not against more memory in the TI, but if I have to choose I would prefer it to be on the CPU bus instead of having to go through the VDP. If this type of thing would be possible, as a developer I would probably choose that route instead.
Curious why you thought you would get flack for posting this, seems like a perfectly good use case to me...
-
1
-
-
Does this count (I posted it half a year ago already)? It's running on the Geneve, though.
In my FRACTALS program I made use of several 9938 features:
- Clear screen with fill command
- Multicolored mouse pointer
- Graphics mode 6 (512x212)
- Definable color palette
- Zoom window is drawn with line command using XOR mode
- and mouse, of course.
Yeah saw it before, that's a pretty nifty example. I also know that there's at least one arcade style game for the Geneve, but the name is eluding me. Either way, showing off more Geneve stuff is great, except for some very basic fiddling in MESS I haven't had any opportunity to see what it can do.
Do you think this fractal program is something that could run on the TI as well? Slower obviously, but would it be possible? Also, how long does it take the Geneve to generate one screen?
-
Thinking about this some more, wouldn't the F18A's ECM enhanced 80 column text mode be a good candidate for a GUI project? This effectively gives you a resolution of 480x192 (or 480x240 if you enabled 30 row mode), and besides text, some widgets, icons and window borders you don't need that many character definitions so it should fit in VDP memory just fine.Should display quite a bit nicer than Geos or The Final Cartridge on the C64...
Just replying to myself here... of course the problem with the above is that in all pattern modes (which is basically all we have) the windows would only be able to move in row/column boundary increments which would make it look a little bit odd. Maybe one could render the active window to the bitmap layer and "snap" it onto the grid when you put it in the background? Sounds convoluted though, maybe moving on grid boundaries isn't too bad...
-
All I know is there are some impressive MSX2 demos out there. The music in this is horrible but it shows quite a few lines being updated per frame.
That's a good one. But yeah, definitely some cool MSX2 demos and games that show off some of the v9938 features, as I said, I'm not knocking the chip itself. It's just that I have never seen anything cool done with it on the TI. And I think there's two reasons for that: the TI crowd has always been of the more serious kind, much more into 80 columns than into games and such; but I think the second reason is that the design of the TI makes it incredibly difficult to pull stuff like that off. We have one third of the bandwidth to the VDP compared to the z80 guys and no matter how much VRAM you have these demos require you to push new data to the VDP at much higher rates than we can push from the TMS9900. None of these things are drawn using lines, patterns or block moves, so they're all being rendered by the CPU and more or less full frames pushed to the VDP.
Now, I'd love to see what people can get out of their TI's with 80 column cards in terms of graphics, so I'm eager to see more (and hopefully) better showcases of what the combination is worth. Just thought I'd kick things off since these videos seem to be rarer than hen's teeth... and I never had the pleasure of owning a vintage 80 columns card.
-
Kinda hard to watch that Video as it is labeled PRIVATE so no one can watch it.
Like I said before show me F18 programs to compare please.
Otherwise you are pushing pure vaporware from your imagination and that is nutty to knock a real product in favor of a fiction in your mind only.
Apologies, the video was not meant to be private. Should be changed now, if you scroll up you should see the clip.
Don't get me wrong, Rich. I'm not trying to push the F18A on anyone and would not have made the comparison if you hadn't. I don't think the F18A is the best thing since sliced bread (I think the Master System VDP has a nicer programming model and stays closer to the tms9918a at the same time), nor do I think the v99x8 is a piece of crap. I'm genuinely interested in all upgraded VDP solutions out there and have been since before I learned of the F18A.
But looking at the examples you've given, I just don't see any of the super duper cool shit you've been talking about, so should I consider that vaporware as well? If you really want, I can point you to two videos that have been made by people on this forum that are freely available on youtube and show the F18A doing things that the v9938 is not able to do. I don't want to foul up a v99x8 thread by posting it full of F18A stuff, but if you insist I'll happily oblige.
But do me a favor, and spend some time setting up MESS with EVPC support (like I did), and make some videos that showcase things that you think are cool examples of Yamaha VDP gloriousness. It's not fair for you to blame me for not showing you F18A examples while you won't show me anything from the v9938/9958 either.
-
Number of Pixels is very important as the less you have the more crappy the display looks and the more blocky it gets.
VRAM allows more pixels. Who cares if you have more pixels but not enough space to load anything on the TI?
This is the major issue the 9938/9958 have as a advantage also you can NEVER MAKE a version of Y.A.P,P. or XHI (XB version of TML) on the F18 as where the hell would you store and run it from?
The 9938/9958 are much older chips but had hardware registers for transfer of VRAM to RAM or RAM to VRAM.
Show me a single program on the F18 software to touch those programs please.
The only possible way is to use the SAMS and you have to use RAM to pull that off so gunna be a huge program.
Did you read my other post as well? The F18A actually displays more pixels, I would still like to know where you get the "4 times more" figure from.
As for VRAM, like I said before: I'm not denying more VRAM gives more possibilities. But even the v9938 supports a configuration of only 16kb, and the only thing you lose is the two more colorful bitmap modes. But those aren't useful for games, only if you want to display a static colorful picture.
But just to make sure I understood your argument as well as I could, I hunted around a little bit to find disks for YAPP and XHI. It took me a while, but I did find them. Below you can see a video of the "HIRESDEMO" program that came with the XHI disk, made in MESS with the EVPC driver (so using a v9938). Frankly, I'm not impressed... all I see is a slightly more colorful version of what the @pesoft guys were able to do on the stock tms9918a. Be warned though, the video is a bit boring and I gave up after 18 minutes. You'll also see me go into the MESS tab menu to speed things up a bit by toggling the throttle, so on real iron this would've been even slower.
I also found YAPP, but in all honesty I couldn't figure out what to do with it without the manual. It loads, I get the main drawing screen (with one-colored sprite as a cursor, yuck...), but I can't figure out how to use it. Maybe you can give it a go and record a video? The .dsk files are linked here, and I can give you the MESS command line for the EVPC driver if you want.
ftp://ftp.nekochan.net/pub/sites/ftp.whtech.com/mess/disks/YAPP55.dsk
ftp://ftp.nekochan.net/pub/sites/ftp.whtech.com/mess/disks/XHI.dsk
Suffice it to say, I'm not impressed at all, XHI is dog-slow and YAPP looks like only half a step above TI Artist. Are there any other programs on the TI that use the v9938's features well? I know the chip is capable of much more looking at what the MSX guys have done with it, but I don't know if the TI ever used it for anything really cool.
-
1
-
-
Having more VRAM would actually benefit the TI a lot. You can preload more data into the VRAM to have it displayed on screen without delays from the slow CPU during gameplay.
That's certainly true, and I didn't mean to say that more VRAM isn't a good thing to have. It's just not the most important thing, imho.
It's worth considering that the amount of data that you need to transfer to the VDP during gameplay per frame is relatively limited in all but the scariest cases. For scrolling on a single page you need to transfer between 3 and 4 bytes every frame. Hardly "overkill" for the system. Now, if you need to upload a whole bunch of new tile patterns, that can indeed become a significant challenge. But even the genesis has only 64kb of VRAM (and again a very similar VDP architecture based on the original tms9918a design), and I'm not asking for Genesis quality games on the TI. I'd be plenty happy with more NES/SMS level games first.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Magellan
in TI-99/4A Development
Posted
Excellent work, this will undoubtedly be very useful to me once I restart my Alex Kidd porting project. I would suggest however that you consider allowing more than 255 patterns to be loaded while editing and only enforce the limitation when saving. That way you can import a detailed png and simplify the drawing for the TI all within Magellan. Or even allow exporting all of the definitions (you might want to upload new patterns to the VDP during gameplay).