Drawing without Sprites in 7800basic (line drawing function)

[M12]

Can images be drawn without the use of sprites in 7800basic? I'm guessing one has to use the asm command to use some assembly. The main reason to draw pixel by pixel is because I currently have a wonky implementation of drawing a line by lining up sprites. I was wondering if there was a method (probably in assembly) that draws a pixel-based line.

 

My sprite based implementation is in 7800basic, and it calculates slope and whatnot. Then it chooses certain sprites based off of the slope and then draws them from one end of the line to the other end. But this is probably a really bad way of drawing a line.

 

The implementation I'm hoping for is one that takes an x0, y0, x1, y1, and draws pixels from (x0,y0) up until (x1,y1). I'm looking through the following thread from atari-forum.com: "http://www.atari-forum.com/viewtopic.php?t=9549," but I'm not sure how helpful it is for me.

 

Edit: One attempt is to use the code:

	* INPUT: d0.w: X1 
	* d1.w: Y1 
	* d2.w: X2 
	* d3.w: Y2 
	* d6.w: highcolor word (color of line) 
	* a0: start of screenaddress	
	DRAW_TRUELINE         
	move.l d2,d4 
	move.l d3,d5 
	sub.w d0,d2 ; / calculate the absolute 
	bpl.s .ok ; | value of the difference 
	neg.w d2 ; \ between X1 and X2 
	.ok sub.w d1,d3 ; / calculate the absolute 
	bpl.s .ok2 ; | value of the difference 
	neg.w d3 ; \ between Y1 and Y2 
	.ok2 cmp.w d2,d3 
	bhi.s .ver 
	* Part for dX > dY 
	cmp.w d0,d4 ; / Get the 
	bhs.s .do2 ; | heighest 
	exg d0,d4 ; | X and Y 
	exg d1,d5 ; \ in d4.w and d5.w 
	.do2 moveq #10,d2 ; \put #640 
	lsl.l #6,d2 ; /in d2.l (bytes in scanline) 
	sub.w d0,d4 
	sub.w d1,d5 
	add.l d0,d0 
	adda.l d0,a0 
	mulu.w d2,d1 
	adda.l d1,a0 
	tst.w d5 
	bpl.s .poo 
	neg.w d5 ; / make the 
	neg.l d2 ; | dX absolute 
	.poo swap d5 ; | and negate the scanline- 
	addq.w #1,d4 ; \ offset if needed 
	divu.w d4,d5 ; d5.w: steepness 
	moveq #0,d0 
	subq.w #1,d4 ; d4.w: number of times to loop 

	.lp2 add.w d5,d0 ; / check if you need to jump to 
	bcc.s .mov ; \ the next scanline 
	adda.l d2,a0 ; jump to the next scanline 
	.mov move.w d6,(a0)+ ; plot and go to next pixel 
	dbra d4,.lp2 
	rts 

	* Part for dX =< dY 
	.ver cmp.w d0,d4 
	bhs.s .do 
	exg d0,d4 
	exg d1,d5 
	.do moveq #10,d2 ; \put #640 
	lsl.l #6,d2 ; /in d2.l (bytes in scanline) 
	sub.w d0,d4 
	sub.w d1,d5 
	add.l d0,d0 
	adda.l d0,a0 
	mulu.w d2,d1 
	adda.l d1,a0 ; a0: address of first pixel 
	tst.w d5 ; / make the 
	bpl.s .shitt ; | dY absolute 
	neg.w d5 ; | and negate the scanline- 
	neg.l d2 ; \ offset if needed 
	.shitt swap d4 
	addq.w #1,d5 
	divu.w d5,d4 ; d4.w: steepness 
	moveq #0,d0 
	subq.w #1,d5 ; d5.w: number of times to loop 

	.lp add.w d4,d0 ; / check if you need to jump to 
	bcc.s .movie ; \ the next pixel in the scanline 
	addq.l #2,a0 ; go to next pixel in scanline 
	.movie move.w d6,(a0) ; plot the pixel 
	adda.l d2,a0 ; go to next scanline 
	dbra d5,.lp 
	rts 

which I got from the linked thread. But I am unsure of a lot of things. Such as: What is the starting address of the screen? How do I call this subroutine? I see that it ends in an rts statement, so should it be called in 7800 basic as a function call? Or should I just use goto and labels for this?

Edited August 19, 2015 by M12

[Mord]

All the graphics on the 7800 is pretty much based on drawing sprites, so I doubt you'd be able to get around making a line without building it up from sprites. The 7800 doesn't have any video ram for a bitmap display so you can't just poke data somewhere to turn specific pixels on.

[Mord]

That being said, you can probably fake it if you had a cartridge with 16k of ram on it to hold graphics data that the 7800 will have set up to display in it's display lists in direct mode such that it can act like a bitmap display.

 

That would require you to write a function that knows how to change the data correctly based on coordinates given to it and a whole bunch of other headaches. I didn't do any calculations so not 100% sure if 16k of ram would be large enough or not.

 

Dammit, I'm going to end up wanting to test this now before too long.

[PacManPlus]

It is possible (as per my example here), but my line drawing routine is currently a little too slow. You can actually see the 'Battlezone' title being drawn.

I *think* trying to do multi-color lines would be even worse.

 

*Please note that this is an 'XM' game due to the extra memory needed for the 'faux bitmap display' as Mord pointed out.

*EDIT - I should also note that this is only a title screen demo, not anything even interactive, let alone playable.

 

I've also included the source code. If someone can make the lines draw faster, I only ask that they let me know so I can eventually get back to this.

 

Bob

BZone78.A78

BZone78.ASM

Edited August 19, 2015 by PacManPlus

[RevEng]

Can images be drawn without the use of sprites in 7800basic? I'm guessing one has to use the asm command to use some assembly. The main reason to draw pixel by pixel is because I currently have a wonky implementation of drawing a line by lining up sprites. I was wondering if there was a method (probably in assembly) that draws a pixel-based line.

The code you link to is Atari ST 68000 assembly, which isn't compatible with the 6502.

 

As others have stated, line drawing is a bit of an unnatural act for the 7800. It can be done, but there's a price to pay in memory, display speed, and code complexity.

[Mord]

I guess the better question is, in what instances would one -need- to do things without sprites. I can think of some special effects types of stuff where the graphic would need to be manipulated on the fly with a routine, but overall not sure how useful it would be over using actual sprites.

 

Speaking about games themselves here, which is the intent of the 7800. I can easily see wanting to use a faked video ram for the display if you were making a paint program/etc.

[Jaynz]

Speaking about games themselves here, which is the intent of the 7800. I can easily see wanting to use a faked video ram for the display if you were making a paint program/etc.

Tempest playfield. Qix. There are a few other situations were a sprite-substitute wouldn't work or look terribly right. Large vectors are where things really break down (re: Defender's terrain).

[Mord]

Well, if you wanted to backport Tempest that could certainly use it, although large vectors would require a lot of updating, which the 7800 would have a hard time keeping up with.

 

This kind of thing could potentially help sprite based games as well anyway if you could run a function that would take a source sprite then draw it with some modifications added in. (Zooming/flipping/rotating/etc)