Jump to content

Recommended Posts

10 hours ago, arcadeshopper said:

on the NABU this is split screen half bitmap and half multicolor

     <snip>

 

That looks like it is all Bitmap to me. Multicolor pixels are  equivalent to 4x4 Bitmap pixels. The entire screen is displaying Bitmap pixels.

 

...lee

As my MultiColor library is now about 70% complete I wanted to share a short demo with you. Though I am working on a write-through mode, the library actually expects you to paint your frame in a CPU memory buffer and the push it to VRAM when ready. You helped me very much to speed up that sync.

 

This demo shows some line-drawing and the use of sprites in MultiColor Mode in XB and normal Speed:

 

image.gif.af167195aeb76ddb158630caa1d71fb6.gif

 

This is the code in SXB:

Spoiler

CALL LOAD("DSK4.MCOLOR.OBJ")
CALL SCREEN(2)
CALL MCOLOR(4,0)

CALL CHAR(40,"0001010100030509090103030301010380C0D0D098D0E8D8C0C0E0E060404060")
CALL SPRITE(#1,40,16,50,50,5,10)


FOR I=1 TO 20
  CALL MCCLR(4)
  CALL HLINE(24-i,32-i,11,i*2)
  CALL VLINE(25-i,32-i,11,i*2)
  CALL HLINE(24+i,33-i,11,i*2)
  CALL VLINE(24-i,32+i,11,i*2)
  CALL LINE(8,30-i,32,30+i,9)
  CALL LINE(8,1,i,64-i,15)
  CALL MCSYNC
NEXT I


REPEAT
   CALL KEY(3,K,S)
UNTIL s<>0

END

 

... and this in Standard XB

Spoiler

100 CALL LOAD("DSK4.MCOLOR.OBJ")
110 CALL SCREEN(2)
120 CALL LINK("MCOLOR",4,0)
130 call char(40,"0001010100030509090103030301010380C0D0D098D0E8D8C0C0E0E060404060")
140 call sprite(#1,40,16,50,50,5,10)
150 FOR I=1 TO 20
160 CALL LINK("MCCLR",4)
170 CALL LINK("HLINE",24-i,32-i,11,i*2)
180 CALL LINK("VLINE",25-i,32-i,11,i*2)
190 CALL LINK("HLINE",24+i,33-i,11,i*2)
200 CALL LINK("VLINE",24-i,32+i,11,i*2)
210 CALL LINK("LINE",8,30-i,32,30+i,9)
220 CALL LINK("LINE",8,1,i,64-i,15)
230 CALL LINK("MCSYNC")
240 NEXT I
250 CALL KEY(3,K,S)
260 IF NOT (s<>0) THEN 250
270 END

 

Much of the time is spent in that CALL from XB, so once finished, I need to create a version to use with Harry's Compiler.

 

 

 

  • Like 10
5 hours ago, SteveB said:

As my MultiColor library is now about 70% complete I wanted to share a short demo with you. Though I am working on a write-through mode, the library actually expects you to paint your frame in a CPU memory buffer and the push it to VRAM when ready. You helped me very much to speed up that sync.

 

This demo shows some line-drawing and the use of sprites in MultiColor Mode in XB and normal Speed:

 

image.gif.af167195aeb76ddb158630caa1d71fb6.gif

 

This is the code in SXB:

  Reveal hidden contents

CALL LOAD("DSK4.MCOLOR.OBJ")
CALL SCREEN(2)
CALL MCOLOR(4,0)

CALL CHAR(40,"0001010100030509090103030301010380C0D0D098D0E8D8C0C0E0E060404060")
CALL SPRITE(#1,40,16,50,50,5,10)


FOR I=1 TO 20
  CALL MCCLR(4)
  CALL HLINE(24-i,32-i,11,i*2)
  CALL VLINE(25-i,32-i,11,i*2)
  CALL HLINE(24+i,33-i,11,i*2)
  CALL VLINE(24-i,32+i,11,i*2)
  CALL LINE(8,30-i,32,30+i,9)
  CALL LINE(8,1,i,64-i,15)
  CALL MCSYNC
NEXT I


REPEAT
   CALL KEY(3,K,S)
UNTIL s<>0

END

 

... and this in Standard XB

  Reveal hidden contents

100 CALL LOAD("DSK4.MCOLOR.OBJ")
110 CALL SCREEN(2)
120 CALL LINK("MCOLOR",4,0)
130 call char(40,"0001010100030509090103030301010380C0D0D098D0E8D8C0C0E0E060404060")
140 call sprite(#1,40,16,50,50,5,10)
150 FOR I=1 TO 20
160 CALL LINK("MCCLR",4)
170 CALL LINK("HLINE",24-i,32-i,11,i*2)
180 CALL LINK("VLINE",25-i,32-i,11,i*2)
190 CALL LINK("HLINE",24+i,33-i,11,i*2)
200 CALL LINK("VLINE",24-i,32+i,11,i*2)
210 CALL LINK("LINE",8,30-i,32,30+i,9)
220 CALL LINK("LINE",8,1,i,64-i,15)
230 CALL LINK("MCSYNC")
240 NEXT I
250 CALL KEY(3,K,S)
260 IF NOT (s<>0) THEN 250
270 END

 

Much of the time is spent in that CALL from XB, so once finished, I need to create a version to use with Harry's Compiler.

 

 

 

Does rxb have bitmap or dot drawing? Might be worth investigating

Trying to run XB with Bit Map mode or Multicolor mode almost requires being compiled as not much XB code is left as 80% of the work is Assembly.

This is why you see more CALL LINK routines then you see XB code. (The amount of time the CPU is running Assembly not GPL/XB code)

It is kind of odd as might as well go full assembly instead of XB as it is not really XB anymore.

  • Like 1
On 1/15/2023 at 7:50 PM, SteveB said:

Though I am working on a write-through mode, the library actually expects you to paint your frame in a CPU memory buffer and the push it to VRAM when ready.

I spent an evening implementing the "write-through" ... and it really sucks. Provided someone would use the library, would you prefer a speed-up in all drawing or the ability to draw directly on the screen? Trick question ... you are all speed-buffs. Instead of painting pixel by pixel, calculating each pixel buffer-address anew (and updating half a byte in the VDP RAM), I might just INC to go down or AI 64 to go right ... the columns based buffer is so much easer to use than the VDP RAM layout.

 

I'll sleep over it, but I guess I will dump the write-through idea in favor of a better frame-rate and update the buffer outside of SETPIX() directly. 

 

Object now or ...

 

  • Like 3
On 1/4/2023 at 12:21 AM, SteveB said:

My calculation based on the data sheet is just as wrong ... but together we will get to the ancient core .. 

From the author:

"it actually uses TWO graphics modes, and changes it mid frame.

it is a very complicated bit of software, compared to other games.

halfway down the screen, we flip the graphics mode. this allows use to use a simpler graphics 1 mode for the betting table.

Roulette was my first game. I wrote it with the guidance and help of Ken Shimizu"

 

Unfortunately the source is lost..

  • Like 3
15 hours ago, arcadeshopper said:

From the author:

"it actually uses TWO graphics modes, and changes it mid frame.

it is a very complicated bit of software, compared to other games.

halfway down the screen, we flip the graphics mode. this allows use to use a simpler graphics 1 mode for the betting table.

Roulette was my first game. I wrote it with the guidance and help of Ken Shimizu"

 

Unfortunately the source is lost..

Ah, graphics 1 is the normal 24x32 character graphics mode that we normally use on the TI - so he's probably using bitmap on the top and switching to graphics mode for the bottom.

50 minutes ago, Tursi said:

Ah, graphics 1 is the normal 24x32 character graphics mode that we normally use on the TI - so he's probably using bitmap on the top and switching to graphics mode for the bottom.

Yes, but then no multicolor mode, which this thread is all about. 😉

 

16 minutes ago, Asmusr said:

You could get the same result, or better, from using bitmap mode on the whole screen.

here's the effect 

 

 

  • Like 1
  • Thanks 1

Another demo at actual XB speed of the multicolor library I am working on...

Imagine sitting in a train to Bisbee, AZ and look out of your window ... about one frame per second with clearing the entire screen, painting the sky and 10 shapes in each and every frame...

 

CALL LOAD("DSK4.MCOLOR.OBJ")
CALL SCREEN(2)
CALL MCOLOR(10)

DIM A(5),T(10),X(10),Y(10),D(10) // Shapes-Address A, Types, X/Y Pos, Delta movement

CALL SHAPE(A(0),16,6,"00022000000001010000020000330011222CCCCCCCCCCCC1")
CALL SHAPE2("0022222CC222222103300002200000B1000003330000000E")
CALL SHAPE(A(1),12,5,"00333000010000000220001BCCCCCCCCCCCB0000C333333B0033C00000BB")
CALL SHAPE(A(2),8,4,"0220000000CC00112222222B3330000B")
CALL SHAPE(A(3),6,12,"00FF000FFFF00FF0F00F0FFF00FFFF0FFFFFFFFFFFFFFFF0FFFFF0FFFFFF0FFFFF000FF0")
CALL SHAPE(A(4),6,5,"0BBB00BBBBB0BBBBB0BBBBB00BBB00")
CALL SHAPE(A(5),4,20,"444A4AAA4AAAAAAAAAAAAAAA4AA44A4A44AA44AA444A444444444444444A44AA44AA4AAA4AAA4AAA")

FOR I=0 TO 9
  READ T(I),Y(I),X(I),D(I)
NEXT I

REPEAT
  CALL MCCLR(10)
  CALL SQUARE(0,0,8,63,4)
  FOR I=0 TO 9
    CALL BLIT(A(T(I)),Y(I),X(I))
    X(I)=X(I)-D(I)
    IF X(I)<-6 THEN X(I)=66
  NEXT I
  CALL MCSYNC
  CALL KEY(3,K,S)
UNTIL S=1
END

DATA 4,2,55,0.2
DATA 3,1,62,0.5
DATA 3,2,24,0.5
DATA 5,7,40,0.6
DATA 2,7,30,0.7
DATA 2,8,5,0.6
DATA 1,13,60,0.8
DATA 1,11,17,0.7
DATA 0,24,20,1.8
DATA 0,28,50,2

 

PS: Which video format do I need to embed the video?

 

Edited by SteveB
  • Like 3
26 minutes ago, SteveB said:

PS: Which video format do I need to embed the video?

I find an MP4 encoded with h.264 and aac works.  It is listed as one of the HTML5 native video/audio codecs.  To encode in ffmpeg, I use -c:v libx264 -c:a aac -ac 2 -ar 44100

  • Like 1
  • Thanks 1

@InsaneMultitasker Are you using Mozilla Firefox as browser?
maybe this could help:https://support.mozilla.org/en-US/questions/1048378

 

I tried on Brave and Chrome and it works for me.

Edited by ti99iuc
  • Like 1
1 hour ago, InsaneMultitasker said:

I see this instead of the video...   :(

image.thumb.png.8b5c7e4ca7c37df3c0c2b25b09fc763b.png

 

Firefox does not like video without an audio track.  His post works fine in Edge.  I suspect it will work in other Chromium browsers, like Chrome and Opera.  They seem a little more lax on things (including security.)

  • Like 1
50 minutes ago, OLD CS1 said:

 

Firefox does not like video without an audio track.  His post works fine in Edge.  I suspect it will work in other Chromium browsers, like Chrome and Opera.  They seem a little more lax on things (including security.)

Roger that.  I'll try Edge.  Don't want to derail the thread any further, it's just that I can count on one, maybe two, hands how many times I've seen that error message here on AA during the past 10 years, and thought it might be a video issue. Thx. 

  • Like 1
  • 3 weeks later...

After many hours of learning and coding I am happy to publish version 1.0 of my Multicolor Library.

 

MColor_V1.0.zip

 

Included in this package are four example programs and a 22 page manual, covering both TiCodEd SXB and standard XB. When using TiCodEd please copy the file Lib/MultiColor.xbpkg to the Lib directory of TiCodEd and select this package on the Project page. The mentioned "Lowercase LINK" and Cactus-Speedbutton will only be available in the upcomming TiCodEd release 2.5, where the package will also be included. I am working on the release and there are two features I am not yet happy with. 

 

Thanks to everyone who supported my project here in this thread and a special thank to Harry and Lee.

 

I hope someone finds this usefull for a project in Multicolor Mode. Suggestions for enhancements are always welcome here. 

  

 

 

PS: I kept "Writethrough" direct drawing as the internal use PUTPIX covered all checks, which would have been implemented all over the place to avoid VRAM corruptions. This way you can safely draw outside of the window, it just gets ignored.
 

  • Like 18

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...