How can i create a program with an elaborate title screen. would i just create a giant 94 x 62 sprite and call it to the screen. or is there some easier way?

In ASM? thats pretty much the way to go. If you want grayscale you actually need a couple of them to flicker back and forth between, twice as long on one.

alright i guess i will do that. also how would i go about creating a map that also has scrolling.

thats where it gets complicated, see if you can come up with a theory on your own and we'll explain what sounds good/what doesn't and such from there.

[edit]
also, you can do it a lot faster without using a sprite when you have a fullscreen chunk of data by using the ldir command to load it in to plotsScreen and then call iFastCopy

First, if you use asm, you'll want a 96*64, not 94*62, because you can use all rows and columns

Draw your title pic somewhere (on your calc, in paint, in photoshop, wherever you want) and save/export it as a .bmp file on your computer.
Then, download IStudio 2.3 and open it. Open your .bmp title screen and under the "image" tab, choose the greyscale you want for the image. For now, I recommend you using monochrome (B&W). Then, click on the text icon and output the file as z80 assembly, no compression (at least, for now), in .db format. Now click OK and save the file with some name. It will output the file in .asm format, that you can open in notepad or any good text editor.

Then, copy/paste the code into your game source code. All you need to do now is to do a little code to transfer the picture on the screen in your program (such as fastcopyb, or the ldir/fastcopy combo)

[Edit: W00t!! 5 posts in between my answer and the original post.

For greyscale, you might try to use RigView's title-pic program maker. Or you can just use Istudio and select the image option 4-level greyscale (2 layers) or 8-level. Then, just do a loop displaying the 3 images in a very fast repetition]

I could create a map using Calc GS but i do not know how i would display the different tiles or i could just create a giant sprite. Than to do hit detection i could use igetpixel or whatever the command is. But than the scrolling part is where i would have to do some thinking.

For 68k, I just store a 240x128 gs pic in my program and then memcpy() it to the screen

for z80, I suggest simply ldir (i think that's the right one XD )into the graphbuffer

edit:
btw, that pic takes up 7680 bytes, which is kinda a waste of space, but if it's too complicated a pic to write a routine to render, it's worth it.

maps -> tiles
tile = tilemapping techniques

yes, its ldir

Calc GS is probably what you will want to use. The giant sprite idea is creative, and is what's known as table based maps, but they tend to be more memory intensive for big games, and require a lot more work.
Now to access a map stored in memory, you have to think of it as a matrix.
for example, the code

Code:


could refer to a 1*4, 2*2, or 4*1 matrix of bytes, or a much bigger matrix of bits. The issue here is then how to access it.
You would create a nested loop (probably a for loop in a high level language, its up to you how to do it in asm) and loop through the data parts of the data you want to appear on screen, figure out which tile should be drawn by the data at that location, and then move on to the next one. However because there is no "structure" to the memory (you think of it however you want) and you are working at machine level, the is now a[0][2] sort of syntax in Asm. thus you have to take your (row number) * (tiles per row) + column number, load that piece of data, find out what tile to display, then display i.t

It is ldir. However, *768, not 7680.

7680 = gs pic for 68k screen

Ah, gotcha. That's for 8-level grayscale, though, not 4-level. Anyway, that's still pretty steep, even with the amount of RAM the 68ks have.

yeah, but if its a title pic, it could just be in a seperate program/file and then archived, thus freeing up that RAM

I usually store everything externally, I think it's easier that way, since most stuff will be static (or constant? not sure which one's the right term) anyways.

I also make one title screen for both 89 family and v200/92+ screens so that 89 files can run on v200 and v200 files can run on 89 w/o a hitch. That means 240 pxls / 8 bits per byte *128 bytes *2 gs planes = 7680

back on topic:

if you're trying to make a scrolling screen for a map, then what you're looking for is a tilemapper, not something to display title screens. Basically, you create a world by using tiles, kinda like carpet tiles on the floor. The challenge is getting those tiles on the screen. The added challenge is to get only parts of the tiles to show, and thus allowing for smooth scroll.

the two major types I know of are:
1.) draw a map bigger than the screen to a buffer in the program, then display the part of the screen you're looking at, update the big map if needed
2.) based on map data, draw and scroll tiles to the gbuf and display

and even among these types, the method is totally up to what you want to do.

i think i might try and get a better understanding of asm first because this is a little confusing.

/me thinks that lafferjm shows considerable wisdom in knowing his limits.