Magellan

[artrag]

A quick question how can I select a tile from the map in order to edit it?

[sometimes99er]

Useless answer completely eradicated.

Edited January 15, 2014 by sometimes99er

[artrag]

IMHO it is an essential feature to quickly locate into the current tileset a detail of the map, expecially when you import a PNG image and the tileset is computed automatically.

 

I would "select" it in the tileset by clicking with the right button of the mouse, this would allow an easy copy & past and fast editing.

 

Actually, but it is a matter of personal tases, I would also allow a copy & past of squared areas by holding the right button while selecting a square of tiles to be copied, but there is already a tool for this.

Edited January 15, 2014 by artrag

[sometimes99er]

.

Edited January 20, 2014 by sometimes99er

[Asmusr]

A quick question how can I select a tile from the map in order to edit it?

 

There is a 'Look At' function. It's in the character editor toolbar rather than in the map editor toolbar where it really belongs.

[artrag]

Found! Thanks.

It is not as practical as the right button of the mouse but it does what it is for.

[artrag]

I have found some bugs in magellan v2.1

 

the import function is very buggy:

 

If I try to import a VRAM dump as binary file I get imported only the first 256 character despite of the fact it is a full bitmap image of 768 tiles

I selected USE HEXADECIMAL and BITMAP MODE and i set the correct addresses in the BIN file and I get only 256 tiles

I tried in OPTIONS to set the BITMAP COLOR MODE and all the other modes and to select "EXPANDED CHARACTERS" but the import always works only on 256 tiles!

Try to import OPENING_.BIN and you will see what i mean

shapes are at 0000 hex

map is at 1800 hex

colors are at 2000 hex

 

 

If I try to import a PNG image or a GIF Image using IMPORT -> MAP IMAGE I get only 256 tiles as well, with some specific image formats (I think it is connected to 16 color PNG and 256 color gif, but I'm not sure).

Try to import OPENING_SCREEN.PNG and you will see the problem

OPENING_.bin

Edited May 3, 2014 by artrag

[Asmusr]

Well, yes - it only works with up to 256 tiles. It would not be that difficult to add support for more tiles, but it's not on my todo list right now.

[Asmusr]

I shouldn't hold on to the source code if anyone else wants to improve it further. So here is the latest version with a few small changes and bug fixes (but still only 256 tiles).

Magellan_windows_2_1_1.zip

Magellan_windows-x64_2_1_1.zip

magellan-2.1.1.zip

[+OLD CS1]

Is it possible to put the VDP into bitmap mode in Extended BASIC? I ask here because I would like to export some test screens to XB. When I tried I got a blank screen during the program run.

[senior_falcon]

Is it possible to put the VDP into bitmap mode in Extended BASIC? I ask here because I would like to export some test screens to XB. When I tried I got a blank screen during the program run.

There is more to it than just setting the registers to the bitmap values. You can use "The Missing Link" which can be found in the development resources. This can run XB programs while in bitmapped mode. Also plotting, text in various sizes, etc. You can import pictures in TI Artist format. I think there is another similar package from Germany, but don't know what it is called. I tried one called "Draw and Plot" which was not very good.

[+Ksarul]

You may be looking for the APESoft routines, as they add a lot of graphics manipulation to Extended BASIC. They are also available in the Mechatronics Extended BASIC II module.

[+OLD CS1]

I will have a quick look, thanks. I had hoped the XB environment would easily support bitmap mode as I just want a quick look-see at how a screen will look on the real iron. I will probably get more mileage out of exporting to assembly and compiling (assembling) it as it will be the same environment I work in, ultimately.

Edited September 15, 2014 by OLD CS1

[+Lee Stewart]

I will have a quick look, thanks. I had hoped the XB environment would easily support bitmap mode as I just want a quick look-see at how a screen will look on the real iron. I will probably get more mileage out of exporting to assembly and compiling (assembling) it as it will be the same environment I work in, ultimately.

 

You might try fbForth 2.0 (still in beta 10). If you use split or split2 modes, you can manipulate the bitmap part of the screen manually from the text part (8 text lines in split mode and 4 in split2 mode). You can use the full width of the screen in both modes (dot-columns 0 – 215). You are limited to dot-rows 0 – 127 in split mode and dot-rows 32 – 191 in split2 mode. You can actually do it in full bitmap mode (graphics2) as well—you just can't see what you are typing.

 

...lee

[+OLD CS1]

The only thing I would find useful right now is the ability to print a map directly from within the program. I get that starts getting too platform specific, though. I can for now just export to a graphic image and then print that image from my favorite program.

[+OLD CS1]

I want to make sure I understand bitmap mode so I appreciate any corrections or elaborations.

 

In bitmap mode, there are 768 screen positions (screen image table.) Each image table position contains a value (name) which references one of 256 patterns in the pattern description table and an associated entry in the color table, the latter referenced from one of three tables dependent upon which third of the image table is calling the name.

 

Thus, using mixed conventions so bear with me:

 

tile=SIT(p)

=PDT(INT(p/256),p MOD 256) & CT(INT(p/256), p MOD 256)

 

[note how PDT( x ,y) is intrinsically linked to CT(x,y)]

 

As a result:

 

1) Patterns which exist in one third of the image table must be repeated if they are to be used in more than one one-third part of the image table.

 

To wit: For pattern 240 in pattern table section 0 to be used in image table positions 110 and 320, pattern 240 from section 0 must be repeated somewhere in section 1, not necessarily as pattern 240.

 

2) Patterns which wish to be reused but with a different color set, irrespective of which third of the image table calls them, must be repeated somewhere in the pattern generator table with associated entry in the color table of the desired colors.

 

To wit: For pattern 240 above to be used in image table positions 24 and 48 but with different color settings, pattern 240 must be repeated as another pattern in the same table section but with a differing associated entry in the color table.

 

Given a correct assessment, the question is begged: why do I only have 256 tiles available in Magellan if bitmap mode is defined as three groups of 256 patterns?

Edited September 18, 2014 by OLD CS1

[Asmusr]

I only have time for a short answer. Magellan supports bitmap mode colors but only one set of 256 patterns. I have used it for editing graphics for 'half-bitmap' mode where the same patterns are used all over the screen. Magellan is not a screen editor but a map editor. Even if it supported 3 different pattern sets it could not make assumptions about which part of the map uses which pattern set. Perhaps you're really looking for a screen based bitmap mode editor?

 

Edit: If you can settle for 256 patterns but want to use full bitmap mode on the TI, all you have to do is to copy the patterns and colors 3 times to each VDP RAM table, but this is a waste of VDP RAM. The half bitmap mode where the same patterns/colors are used all over the screen does not allow you to use more than 8 sprites, so the best mode for working with 256 patterns and bitmap mode colors is what I call 2/3 bitmap mode where you have 3 pattern tables and 1 color table. The does not have any sprite issues and uses only 2/3 of the RAM (8K) compared to full bitmap mode (12K). In an assembly game you can easily find a need for the extra RAM - in particular if you want to use F18A multicolor sprites.

[sometimes99er]

Useless answer completely eradicated.

Edited September 18, 2014 by sometimes99er

[Asmusr]

... but colors can't be copied ...

 

Actually bitmap mode colors can be copied in the latest version.

[sometimes99er]

.

Edited September 18, 2014 by sometimes99er

[+OLD CS1]

Okay, so there are more modes for me to understand. For what I am doing right now I think 256 patterns and colors should be sufficient. Future projects may be more ambitious.

[artrag]

Never the less, supporting 768 tiles could be very handy, maybe only when the map is 24 tiles tall...

Anyway, I've also another request: usually one have to make multiple maps sharing the same tile set.

A nice feature could be that when you import a png and you have already a tileset defined you can "lock" the tiles already defined and just add the new tiles in the free positions eventually reusing the tiles that match with those already defined.

In this way you can import pictures and merge the tilesets that give those pictures.

Edited September 18, 2014 by artrag

[Asmusr]

A nice feature could be that when you import a png and you have already a tileset defined you can "lock" the tiles already defined and just add the new tiles in the free positions eventually reusing the tiles that match with those already defined.

In this way you can import pictures and merge the tilesets that give those pictures.

 

A very reasonable request. I have also needed that.

[+OLD CS1]

A nice feature could be that when you import a png and you have already a tileset defined you can "lock" the tiles already defined and just add the new tiles in the free positions eventually reusing the tiles that match with those already defined.

In this way you can import pictures and merge the tilesets that give those pictures.

 

I second this. To work with multiple images I have to set up a different map project for each one.

[+OLD CS1]

Double-posted.

Edited September 19, 2014 by OLD CS1