Pan around a large screen
#1
Lightbulb 
The latest topics created are staying firmly with zero views. Also this new annoyance of "related topics" which picks up only one word such as "bug" or "clone" LOL. I hope there's an user preference to disable that.

Ahem! Here I am sharing an incomplete program that could be used by someone else. It allows the user to press the arrow keys to move around in a simple imaginary world created with SCREEN 0. The "world" isn't very complex, just colored boxes. Feel free to add more keypresses, or "automatic movement" although it could spoil the fun.

Code: (Select All)
DIM AS LONG bigscr
DIM AS INTEGER i, j, x, y, c, ii, fc, bc, xs, ys
DIM upd AS _BYTE
DIM ke$, ba$, blk$

blk$ = CHR$(219)
ba$ = CHR$(177)
RANDOMIZE TIMER

bigscr = _NEWIMAGE(1200, 1200, 0)
_DEST bigscr
FOR ii = 1 TO 5
    FOR i = 1 TO 1000
        DO
            fc = INT(RND * 16)
            bc = INT(RND * 7 + 1)
        LOOP WHILE fc = bc
        xs = INT(RND * INT(i / 25) + 4)
        ys = INT(RND * INT(i / 25) + 4)
        x = INT(RND * (1200 - xs) + 1)
        y = INT(RND * (1200 - ys) + 1)
        COLOR fc, bc
        LOCATE y, x: PRINT STRING$(xs, ba$);
        LOCATE y + ys - 1, x: PRINT STRING$(xs, ba$);
        FOR j = 1 TO ys - 2
            LOCATE y + j, x: PRINT STRING$(xs, ba$);
        NEXT
    NEXT
NEXT
COLOR 15, 0
LOCATE 1, 1: PRINT STRING$(1198, 219);
LOCATE 1200, 1: PRINT STRING$(1198, 219);
FOR j = 2 TO 1199
    LOCATE j, 1: PRINT CHR$(219);
    LOCATE j, 1200: PRINT CHR$(219);
NEXT

SCREEN _NEWIMAGE(100, 40, 0)
_SCREENMOVE 0, 0
_SOURCE bigscr

upd = 1
x = 576
y = 1201 - _HEIGHT
DO
    _LIMIT 50
    IF upd THEN
        FOR j = 39 TO 1 STEP -1
            FOR i = 1 TO 100
                c = SCREEN(y + j - 1, x + i - 1, 1)
                COLOR c MOD 16, c \ 8
                LOCATE j, i: PRINT CHR$(SCREEN(y + j - 1, x + i - 1));
            NEXT
        NEXT
        j = 40
        FOR i = 1 TO 98
            c = SCREEN(y + j - 1, x + i - 1, 1)
            COLOR c MOD 16, c \ 8
            LOCATE j, i: PRINT CHR$(SCREEN(y + j - 1, x + i - 1));
        NEXT
        _DISPLAY
    END IF
    ke$ = INKEY$
    IF ke$ = CHR$(27) THEN EXIT DO
    IF LEN(ke$) > 1 THEN
        kk = ASC(ke$, 2)
        SELECT CASE kk
            CASE 72
                IF y > 1 THEN y = y - 1: upd = 1
            CASE 75
                IF x > 1 THEN x = x - 1: upd = 1
            CASE 77
                IF x <= 1100 THEN x = x + 1: upd = 1
            CASE 80
                IF y <= 1160 THEN y = y + 1: upd = 1
        END SELECT
    END IF
LOOP
_AUTODISPLAY
SYSTEM
Reply
#2
I had puzzled over the "larger world" problem... which is what I called what you're calling it. World bigger then the screen.

I did mine in graphics. I populated my "giant world" like a universe... random sized and colored circles, which were meant to be planets. Even named them with a letter and number scheme, so, they seemed more like planet designations.

I found out... the SIZE of my giant world? had no limits the way I did it. The only difference was how "long" it tool for the player to "cruise" across the "universe"

this led me to fooling around with "larger than screen" graphics.
Eventually made "maps" to games which I never made, which you could scroll around on.

I can see now, I'm not the only one interested in programming a "larger world" scenario
Reply
#3
I purposely did this program with SCREEN 0 because graphics screens gobble up a lot of RAM...

It's entirely possible to do a "large" world in graphics. It's done by storing the locations of items like trees, buildings, stones part of the terrain and so on. Easier to store the composition of tangible items, harder to keep track of volatile things that could be extended such as a river or the clouds in the sky. This is true whether two-dimensional or three-dimensional graphics is demanded. 3D is hard for someone who doesn't understand the concepts. Everytime the user moves around in the world, a search has to be performed on the database for objects in the vicinity of the user that have to be drawn. That's why programming an RPG could be difficult for one person even if time weren't an objective.

My example just draws weak things on a large screen in which every "pixel" is stored, which is good for performance but it's not very sophisticated.
Reply
#4
my world was definitely not 3-d, lol...

I simply stored planet sizes and colors and name designations...

it worked. it allowed you to move around a "universe" and approach planets and stuff.
the same technique rolled over into a "map". Allowed me to do scrolling maps.

one map looked suspiciously like someone doing a "take" of river raid scrolling, lol.
Reply




Users browsing this thread: 2 Guest(s)