Mode 1 Help

Got a programming project in mind? Tell everyone about it!
User avatar
FourthStone
Posts: 400
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Mode 1 Help

Postby FourthStone » Thu Dec 08, 2016 11:26 pm

Hi All,

I am after some examples of mode 1 sprite routines in asm, I have been searching the forum but haven't found anything specific so any links to existing write ups would be much appreciated. Also something to plot text would be good, I am currently using OSWRCH for status etc but eventually want to use my own routines.

I am slowly (re) teaching myself assembler and just need a bit of a reference point to see if I can maybe do things in a smarter, more efficient way with regards to calculating screen co-ordinates and sprite data management etc. My starting point for the game loop is the very excellent beebasm rotating globe demo which I have modified for my own purposes, thank you Mr Talbot-Watkins =D>

I am working on a little demo that animates a horse running across the screen at a fixed y position. The second screen of the demo will show a character running across the screen and into a castle... door prize for anyone who can guess what game this is from :wink:

There are 6 frames in the animation and to allow single pixel movement I have created twelve sprites with each one being offset by two pixels. The current sprite routine I have written is basically a big unrolled loop that plots vertical strips of bytes in the required location. To minimize screen writes I don't plot blank bytes unless required for erasing by adding the required screen offset to jump down to the next required byte location.

In terms of sprite masking I am using a basic approach of not plotting anything if there something already on the screen so that my sprite appears to go behind the scenery. For this I am using a table that tracks any screen data found at the leading edge of my animation frame, maybe I can do this better too.

It's not quite ready for a showing, but as soon as I get the first screen working smoothly I hope to upload it for people to review, comment, help out, critique [-o<

Cheers

P.S. Apologies for the wall of text #-o

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Fri Dec 09, 2016 7:35 am

It sounds like you are going the right direction.
Mode 1 plotting is really the same as any graphics mode, except making the images, so just look for anything.
There are quite a few samples on retrosoftware.
I have posted the source for most of my games around here somewhere, but I usually have a custom routine for each type of movement.
I usually start with with anything that can just be copied to the screen and then if i can get away with it, or on anything which might overlap.
Frogger just copies on each moving object, but is unrolled for each height in bytes and number of copies to draw. These are the most efficient sort of sprites, load once, store many.
I've just realised that there probably isn't much of this in a Zelda game, so you might be better off looking at RichTWs sprite routines, which are fast and general purpose.
The source should be up for my vertically scrolling game framework, which redraws the screen where the sprite was and then masks the sprite in its new position (probably on rs). It is mode 5, but that is just to save memory. It uses a popular trick of making the screen 256 bytes wide to make vertical movement calculations trivial and also to save memory.
The source for Jeltron is also on rs, which has a table to decide what to do for each screen character and then draws the first thing in a character and it's the rest.
Sorry, that lot probably didn't help much :)

User avatar
FourthStone
Posts: 400
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: Mode 1 Help

Postby FourthStone » Fri Dec 09, 2016 10:17 am

Thanks Tricky :D

I've been pouring over the Jeltron source, I must admit things take a while to sink in for me haha, it's so humbling to see how far a good coder can push the beeb. Trying to absorb some of the magic and actually starting a project has been really good for reinforcing the sometimes obscure coding tricks and general logic optimisations used. Small steps... At the moment I am spending a lot of time using a spreadsheet for working out screen addresses, and this is just for a non changing Y single direction animation! Today I spent 1 hour tracking down one address calc bug that was staring me right in the face #-o I'll hunt around for other sources and the general sprite routines by RichTW, i've also got a bunch of beeb asm coding books which contain nuggets of useful info.

Could you elaborate on the 256 byte (pixel?) wide screen trick? Interested to know if I can do something similar for mode 1.

With single pixel movement sprites would you create multiple copies for required pixel offsets using an editor (I'm using Spriter) or create 1 copy and then transform during game initialisation? I've got this vague idea of creating a sprite tool that can export out the code and data to draw the sprites at each pixel offset, need more time to let that idea sink in properly :roll:

Interesting you mention a Zelda game, would be interested working on something like that, the demo I am doing is from an Apple II game which never made it to the beeb :wink:

Your frogger is amazing I must say =D> And I love loading Jeltron and trying to control both ships myself :lol:

Have you made any updates to the Mario or Scrambler demo's?

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Fri Dec 09, 2016 11:06 am

Vertical scrolling demo with masked sprite drawing is here: http://www.retrosoftware.co.uk/forum/viewtopic.php?f=19&t=925&hilit=framework#p7917. RichTWs sprite routing is a beautifully optimized version of the sprite routine in the vertical scrolling framework.
Jeltron source is very hard to read, we wrote it in the eighties in about 7 BASIC source files, which ran after each other *saving bits of code and data and then joined them together afterwards. To get as much in each file, we used two or three character variable names and had a crib sheet with what they meant. I did try to tidy it a bit for uploading and lumped it into a single file, but it didn't help that much.
Two ships at once!!!!!
256 byte wide for modes 4 and 5 and 512 bytes wide for modes 0,1 and 2. You change the horizontal displayed characters and recenter the screen so that mode 4/5 becomes 8K and is one page wide making it a high byte inc/dec to go down/up a line. Same trick with modes 0/1/2, but the high byte changes in twos.
In mode 1, I sometimes store the position of things in pixels, allowing and #&FB : asl for low byte and store the high byte as a row, which I then rol in the C (high bit) of the horizontal position to get the high byte. This doesn't really save much, but can simplify movement and collision.
For Frogger, I store the horizontal position in 1/64ths of a pixel as the scrolling is sub-pixel. I then use the sub-pixel pos AND &C0 as part of the source address (offset into the page) to give me the four pixel offsets (copies of sprite) within a byte. When scrolling, I ADC/SBC #4 to keep the pos in pixels.
For most of my stuff, I generate the pixel offsets off line and just include them in the load - you can see this if you *load them at &3000 in mode 1. For AstroBlaster, because there are so many different enemies and only one type is on screen at once, I just expand them at the beginning of each level.
Sorry, no progress on the mario level drawing demo - I don't think I will be doing any more on this. No progress on Scramble either, but as the original was so well received on the TenPenceArcade http://tenpencearcade.co.uk podcast recently I may come back to it.

User avatar
FourthStone
Posts: 400
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: Mode 1 Help

Postby FourthStone » Fri Dec 09, 2016 9:43 pm

Ok, I've read your post about 5 times now and it's starting to sink in :D The subpixel stuff will take a little longer but I know why you do it, just need to get the maths straight in my head.

I'm going to try and finish the first part of the demo and then get some feedback on how I can improve on it. It's great to be able make changes, compile and load straight into beebem to test. I remember back in the day on real hardware experimenting with asm using the basic compiler and loosing everything after failing to save :shock:

Ta for the link to the ten p arcade!

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Fri Dec 09, 2016 9:53 pm

No problem, I do like the 10p arcade. They change one of the presenters after the first 22 episodes.
Have fun with your demo.

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Sat Dec 10, 2016 9:27 am

If the hundreds of hours of them isn't enough, if you like arcade games you may also like http://www.retroist.com/category/diary-of-an-arcade-employee-podcast/ and if you like Amiga, or just great guests http://www.theretrohour.com/. Both regularly mention other podcasts.

On a more coding related note, if you have a memory scribble, B-em has a watch point that tells you the address of the code that changed a memory location.

For more exotic debugging, beebem is pretty easy to mod and build, at least on windows. The git repo for either may contain full build instructions.

jsbeeb has a great debugging feature of tracking the last 256 instructions visited and can be easily extended if you know a bit of javascript.

The debugger in mame has a few nice tricks, and as long as you don't go crazy with the 6845, it can run quite a bit of stuff.

User avatar
FourthStone
Posts: 400
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: Mode 1 Help

Postby FourthStone » Sat Dec 17, 2016 4:19 am

Ok, finally got around to getting the first screen working mostly ok, posting up as a milestone. It's just one intro screen and was really a test to see if I could actually code something that works. The timing and the sprites aren't exactly the same as the apple II version, maybe I'll come back and redo it.

Spent ages writing and then rewriting sections but I think it's fairly compact and logical, feel free to have a look at the source and let me know how I can make it better or any obvious improvements. It's funny how you can be coding away thinking something will work and then suddenly realise there are big flaws in the logic and you have to make sweeping changes, maybe the seasoned coders don't experience this?

Next stage will be finishing the first intro screen and then adding the second intro screen. Working up towards a full port but don't want to get my hopes up... 1 screen at a time for now :wink:

Let me know what you think :)
Attachments
Conan001.zip
(11.91 KiB) Downloaded 21 times

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Sat Dec 17, 2016 8:39 am

Good start,
I don't want to be picky, but something isn't being initialised properly, I'm mentioning as it will probably catch you out later.
If you SHIFT-BREAK as the horse is half off the right hand side, you get this:
restart_on_right_edge.png
I'll have a look through the code now ;)
I quite like the black edges where the horse goes behind the tree.
I believe everyone rewrites big chunks of their code, they just call it refactoring ;), it's better than rewriting big chunks of nih (not invented here) code.

User avatar
FourthStone
Posts: 400
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: Mode 1 Help

Postby FourthStone » Sat Dec 17, 2016 9:16 am

The good thing about other people is they spot obvious things really quickly :-)

I've noticed in beebem that after escaping out or breaking that the ZP vars misbehave, it might (probably is) be something to do with the buffer I use for drawing behind scenery, I need to initialise it every time. It could also because I'm using OSWRCH to set the screen mode and palette, any tips there would be great for initialising the screen and palette properly using direct pokes.

I'm pretty much assuming everything in memory is clear from a hard reset, i'll look into making sure everything it set every time the code loads or restarts.

The black edges are something I like too, I am thinking of designing each screen to use that too full effect. It's nice and simple how it works which is to not draw if there is already at least one pixel in each character block. Scenery would be designed so that there is always one or two black pixels aligned to where sprites will be drawn therefore leaving a nice black border... the screens in the current demo are just ripped straight from the original game so there could be up to a maximum of 3 black pixels where sprite edges meet scenery... something for the future release :-)


Thanks for the feedback Tricky!

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Sat Dec 17, 2016 9:25 am

A couple of early observations.
As the bytes in a character never cross a page boundary and you know when you are going down a character row, you don't need to keep checking for page boundary crossing. Usually, an unrolled drawing loop like yours would INY and then reset it to 0 on the next row, just saves a few bytes and cycles.

Code: Select all

.c01pix2: INC scrnt: BNE c01pix2a: INC scrnt+1: .c01pix2a: LDA buf1+28: AND #2: BNE c01pix3: LDA c01p00,X: STA (scrnt),Y
.c01pix2: INY : LDA buf1+28: AND #2: BNE c01pix3: LDA c01p00,X: STA (scrnt),Y
I think you will need to reduce the size of your drawing loop, unless you only have a couple of sprites.

It would be a fair change, but if there is a lot of going behind stuff, you might think about having a combined sprite and foreground drawing routine where each screen character would have an index to a mask:

Code: Select all

ldy #7 : .loop
lda (screen),y : and (sprite_mask),y : ora (sprite),y : and (foreground_mask),y : ora (foreground),y : sta (screen),y
dey : bpl loop
The mask is the bits of what is already on screen that you want to keep and allows things like a border around the sprite.
You could duplicate the line inside the loop for the number of characters that you are drawing in the sprite, so you would use quite a few zero page addresses, or you could use addr,y instead of (addr),y and then write the addresses directly into the code each time (self modding code).

A slightly simpler idea, but one that would flicker more if you aren't careful, would be to draw the sprite and then treat the foreground as another sprite and draw it on top if they overlap.

Sorry if I have gone too far, I usually do, and if the level of explanation is wrong, but hopefully it will suit someone.

The main thing is to enjoy what you are doing ;)

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Sat Dec 17, 2016 9:46 am

Sorry, crossed in the post.

Some useful defines:

Code: Select all

   CrtcR0HorizontalTotal        =  0 \\ 8b WO m0-3:127 m4-7:63
   CrtcR1HorizontalDisplayed    =  1 \\ 8b WO m0-3:80  m4-7:40
   CrtcR2HorizontalSyncPosition =  2 \\ 8b WO m0-3:98  m4-6:49 m7:51
   CrtcR3SyncPulseWidths        =  3 \\ Horizontal sync pulse width b0-3 WO m0-3:8 m4-7:4, Vertical sync pulse width b4-7 WO Always 2
   CrtcR4VerticalTotal          =  4 \\ 7b WO m0-2,4-5:38 m3,6-7:30
   CrtcR5VerticalTotalAdjust    =  5 \\ 5b WO m0-7:0
   CrtcR6VerticalDisplayed      =  6 \\ 7b WO m0-2,4-5:32 m3,6-7:25
   CrtcR7VerticalSyncPosition   =  7 \\ 7b WO m0-2,4-5:34 m3,6-7:27
   CrtcR8InterlaceAndControl    =  8 \\ Interlace modes        b0-1 00,10 non-interlaced, m0-6 01 Interlace sync, m7 11 Interlace sync and video
                                     \\ Display blanking delay b4-5 m0-6 00 no delay, m7 01 one character, 10 two characters, 11 disable video output
                                     \\ Cursor blanking delay  b6-7 m0-6 00 no delay, 01 one character, m7 10 two characters, 11 disable cursor output
      CrtcR8_M7_Default  = &93 \\ Interlaced
      CrtcR8_M06_Default = &01 \\ Interlaced
      CrtcR8_M06_Game    = &C0 \\ no interlace, no crsr
      CrtcR8_M06_NoVideo = &F0 \\ no interlace, no crsr, video disabled
   CrtcR9CharacterScanLines     =  9 \\ 5b WO m0-2,4-5:7 m3,6:9 m7:18
   CrtcR10CursorControlStart    = 10 \\ 7b WO b7 unused b6 blink enable b5 blink fast b0-4 crsr start line
   CrtcR11CursorEnd             = 11 \\ 5b WO crsr end line
   CrtcR12Screen1stCharHi       = 12 \\ 6b WO hi byte of (start of screen address)/8
   CrtcR13Screen1stCharLo       = 13 \\ 8b WO lo byte of (start of screen address)/8

   VideoULAVideoControlRegister = VideoULA + 0 \\ 8b WO b7 master crsr size b5-6 crsr bytes wide 00:1 m0,3-4,6 01:undef 10:2 m1,5,6 11:4 m2
                                               \\ b567=000 disables the crsr b4 6845 clock rate 0:m4-7 1:m0-3
                                               \\ b2-3 chars per line 11:80 10:40 01:20 00:10 b1 teletext b0 flash colour set
                                               \\ m0:&9C m1:&D8 m2:&F4 m3:&9C m4:&88 m5:&C4 m6:&88 m7:&4B \\ NB check erata
   
      VideoUlaMode_1NoCrsrFlash0 = &18 \\ non-flash colours
      VideoUlaMode_1NoCrsrFlash1 = &19 \\ flash colours
      VideoUlaMode_4NoCrsr       = &08 \\ lsb flips flash colours
      VideoUlaMode_5NoCrsr       = &04 \\ which could be used to save some palette swapping

Colour defines and setting up a mode code:

Code: Select all

   VideoULAPalette              = VideoULA + 1 \\ b4-7 logical colour 2c:b7xxx 4c:b7xb5x 16c:b7-4, b0-3 actual colour (^7)
                                               \\ c0:black, c1:red, c2:green, c3:yellow, c4:blue, c5:magenta, c6:cyan, c7:white, c8-15:c0-7/c7-0
   PaletteWhite   = &00 : PaletteFlashWhiteBlack   = &08 : Pal2Col0 = &00;
   PaletteCyan    = &01 : PaletteFlashCyanRed      = &09 : Pal2Col1 = &80;
   PaletteMagenta = &02 : PaletteFlashMagentaGreen = &0A
   PaletteBlue    = &03 : PaletteFlashBlueYellow   = &0B
   PaletteYellow  = &04 : PaletteFlashYellowBlue   = &0C : Pal4Col0 = &00;
   PaletteGreen   = &05 : PaletteFlashGreenMagenta = &0D : Pal4Col1 = &20;
   PaletteRed     = &06 : PaletteFlashRedCyan      = &0E : Pal4Col2 = &80;
   PaletteBlack   = &07 : PaletteFlashBlackWhite   = &0F : Pal4Col3 = &A0;
   
.crtc_setup  EQUB 63, 32, 45, &24, 38, 0, 32, 34, CrtcR8_M06_Game, 7, &20, 8, HI(scr_addr/8), LO(scr_addr/8) : .crtc_end

.setup_display
   lda #VideoUlaMode_4NoCrsr : sta VideoULAVideoControlRegister        \\ no crsr, M4, non-flash
   ldx #crtc_end-crtc_setup-1
.set_crtc
   lda crtc_setup,x
   stx CrtcReg : sta CrtcVal
   dex
   bpl set_crtc
   ldx #4+8 : stx SysViaRegB \\ display wrap size
   ldx #5+0 : stx SysViaRegB \\ display wrap size
RTS
Code is from my stars demo (256x256 mode 4), so the crtc, mem size and pallette code is all wrong for you. To see what crtc values you are using, you can open the beebem debugger, break the code and do "state v".

Code: Select all

.setup_colours
   lda #Pal2Col0 OR PaletteBlack : jsr set_palette_colour
   lda #Pal2Col1 OR PaletteWhite : jsr set_palette_colour
RTS

.set_palette_colour \\ A = &pxpxcccc Palette(0=COLOUR0) Colour^7(7=black) \\ delete the first line for 4 colour modes
{
   STA VideoULAPalette : EOR #&10 : STA VideoULAPalette : EOR #&40 : STA VideoULAPalette : EOR #&10 : STA VideoULAPalette : EOR #&20 ; 2 col
   STA VideoULAPalette : EOR #&10 : STA VideoULAPalette : EOR #&40 : STA VideoULAPalette : EOR #&10 : STA VideoULAPalette
   RTS
}
   
Delete the first line of set_palette_colour for 4 colour modes.

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Sat Dec 17, 2016 10:02 am

Having looked at some videos and the gamefaqs walkthrough, I guess you are going to just *LOAD each screen. This would be a little slow on floppy, but fine on SD card. You could add compression to speed up the load and there are a few routines around here.
I'm pretty sure it isn't guaranteed to be safe tp *LOAD with your code/data below PAGE (usually &1900), although on all the common filing systems, I think it is. I make my games load everything up front, so I don't need to worry, but I don't think that is practical here, even with lots of sideways RAM.

User avatar
FourthStone
Posts: 400
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: Mode 1 Help

Postby FourthStone » Sat Dec 17, 2016 9:11 pm

Digesting... please wait :lol:

As the bytes in a character never cross a page boundary...


Awesome! Bit of a rookie mistake for me on this one, I was a bit unsure as I moved across the screen whether it would become an issue so I just wanted the check there to make sure every line. Makes sense that each char would be aligned this way #-o

Having looked at some videos and the gamefaqs walkthrough, I guess you are going to just *LOAD each screen. This would be a little slow on floppy, but fine on SD card. You could add compression to speed up the load and there are a few routines around here.
I'm pretty sure it isn't guaranteed to be safe tp *LOAD with your code/data below PAGE (usually &1900), although on all the common filing systems, I think it is. I make my games load everything up front, so I don't need to worry, but I don't think that is practical here, even with lots of sideways RAM.


Compression will be the way to go, for now it is just a *LOAD but I know i'll need to change it. I loaded code at &1100 only because that is what the sample code used, there doesn't seem to be many options though for having enough ram for code when the screen takes up 20k, going to look at reducing the screen size etc.

Code is from my stars demo (256x256 mode 4), so the crtc, mem size and pallette code is all wrong for you. To see what crtc values you are using, you can open the beebem debugger, break the code and do "state v".


Thanks! I will see if I can wrap my head around the crtc direct pokes, I couldn't quite work out how to change it from the original beebasm sample, another target to aim for =P~

The mask is the bits of what is already on screen that you want to keep and allows things like a border around the sprite.
You could duplicate the line inside the loop for the number of characters that you are drawing in the sprite, so you would use quite a few zero page addresses, or you could use addr,y instead of (addr),y and then write the addresses directly into the code each time (self modding code).

A slightly simpler idea, but one that would flicker more if you aren't careful, would be to draw the sprite and then treat the foreground as another sprite and draw it on top if they overlap.


I'm in two minds about how to handle the actual game sprites, I'm willing to try a few different approaches and see what works the best. For the horse demo it was simple because it's one direction on the same y line, I think for game sprites I will need to adopt either the masking or using foreground sprites or maybe a combination of both...

Sorry if I have gone too far, I usually do, and if the level of explanation is wrong, but hopefully it will suit someone.

The main thing is to enjoy what you are doing ;)


Thanks again for taking time out to go into detail, very much appreciated! I have really enjoyed making the demo so far, I've been really patient and just wanting to get a good understanding of how everything hangs together in an ASM game loop. This is the first time i've gone this far with pure 6502 asm and I wouldn't of been able to do it alone without the help from others =D>

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Sat Dec 17, 2016 11:27 pm

Great, I love to see people try new coding.
My own sprite routines are pretty much different every time, and nearly unreadable.
There is a sprite editor in swift, with a routine to draw them although I didn't get on with it myself.
I've also never written a routine to copy the background and then restore it when the sprite moves, but I've heard several people say they do.
Anyway, enjoy your coding.

User avatar
FourthStone
Posts: 400
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: Mode 1 Help

Postby FourthStone » Wed Dec 21, 2016 2:31 am

Quick update, I've implemented most of the changes you recommended which has reduced the compile size down by quite a bit and also simplified the code somewhat which is great. Refactoring is fun right ? :wink: I introduced a bug with the back buffer code and that took me a while to work out but it all seems to be working now and also doesn't play up after shift breaking at random times, thanks for the 'play' testing there.

I've managed to work out the CRTC and palette code by referencing some demos and the beebwiki page on CRTC. Now experimenting with saving some RAM so I can implement the next part of the intro screen which is animating a rather large bitmap onto the screen. The original game on Apple II runs at 280x192 resolution so I am thinking about reducing the horizontal and vertical screen size to 64x24 chars (256x192 pixels) which would require &3000 bytes down from &5000 and the added bonus of aligning the page boundaries for easier addr calcs. Playing with the CRTC registers and coming up with some strange results so far but will continue to poke around and see if I can work it out.

Anyway, while I was working all this out I made a little spreadsheet helper to work out screen addresses based on char counts etc. Do you know if there is anything else around that does this better? You pro's probably have memorized all the combinations I'd reckon :wink:

ScreenCalc.PNG
Attachments
Conan001.zip
(15.42 KiB) Downloaded 16 times

User avatar
FourthStone
Posts: 400
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: Mode 1 Help

Postby FourthStone » Wed Dec 21, 2016 4:08 am

Hey Tricky, while hunting around for image to sprite converters I came across a post from you on RS... any chance of getting your image to EQUB converter [-o< I have been hand drawing sprites from screen grabs and while I have been thinking of writing a converter myself I thought I'd have a search around to see what others were using. I have written a script to write EQUB statements from Spriter files but I am still drawing them manually at this time :(

I screen capture from MAME, then tweak in PaintShopPro5, then use my own converter to produce data statements in assembler (EQUBs).

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Wed Dec 21, 2016 4:43 pm

Sticking to 256 horizontal pixels, gives either &200 per char row or &100 per char row, so calculating addresses isn't very difficult ;)
There are a few copies of tga2equb around, I usually tweak it depending on whether I want 4 or 8 pixel characters or something more exotic and whether I want complete vertical columns (easier to scroll vertically) or in rows for normal plotting.
It really just boils down to x and y char loops around x and y pixel loops. I'll clean one up and post it for mode 1.
If you have a preferences for layout, I'll do that, of not, it'll be in blocks of 8 bytes per char for one row of chars per equb.
I have a long drive tonight, so it probably won't be until tomorrow evening.
Glad you worked it all out.

User avatar
FourthStone
Posts: 400
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: Mode 1 Help

Postby FourthStone » Wed Dec 21, 2016 9:18 pm

Awesome, thanks heaps Tricky :D

I think the 8 bytes per char would be perfect for now and if I need anything else I can play around with it or transform it etc. If the source is available I don't mind adding tweaks to suit what I am working on but if not I can script up converters.

I have a long drive tonight, so it probably won't be until tomorrow evening.


Hehe I hope your not coding while driving :wink:

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Thu Dec 22, 2016 9:06 am

I didn't have the main tga2equb.cpp, so I've just written it, I hope it is OK!
It's very basic, it expects images to be a multiple of 4x8 and writes one EQUB for each char row, but should be easily tweaked.
It supports 24 and 32 bit non-paletised TGAs and should support RLE TGAs, but I use uncompressed (The writer writes uncompressed).
Good luck.
Edit: forgot to mention that palette.tga should be a 4x1 pixel tga where the first pixel colour will be colour 0 etc. The one included is black, red, yellow and white to match mode 1 defaults.
Attachments
tga2equb.zip
(9.68 KiB) Downloaded 25 times

User avatar
FourthStone
Posts: 400
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: Mode 1 Help

Postby FourthStone » Thu Dec 22, 2016 10:24 pm

:shock:

Thanks Tricky, that goes above and beyond!

I've had a go at compiling and got past all the usual environment pathing issues but I can't seem to resolve the following :?

Compile.PNG


Googling seems to point to missing implementation for constructors but my C is not good enough to know how to fix it. :oops:

Let me know if you have time to have a look, otherwise I can probably write my own now that I had a look at your code. I am really comfortable with VB (and pascal thanks to the beeb!), but for some reason I've just never wrapped my head around advanced C concepts apart from being able to understand the logic enough to make minor modifications....

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Mode 1 Help

Postby tricky » Fri Dec 23, 2016 8:44 am

Those two functions are in tga.cpp.

The first warnings about emulators are because I usually call beebasm from visual studio and then run the resulting .Ssd in an emulator from vs - you can just ignore them.

You should be able to write your own in any language, the only bits that you would need to do differently are use your favourite image class to load the bitmaps [Tga image(filespec)] and access pixels [image(x,y)].


Return to “projects”

Who is online

Users browsing this forum: No registered users and 1 guest