+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Works in Progress (https://qb64phoenix.com/forum/forumdisplay.php?fid=9)
+---- Thread: Pan around a large screen (/showthread.php?tid=1334)
Pan around a large screen - mnrvovrfc - 12-27-2022
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
SYSTEMRE: Pan around a large screen - MrCreemy - 12-29-2022
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
RE: Pan around a large screen - mnrvovrfc - 12-29-2022
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.
RE: Pan around a large screen - MrCreemy - 12-29-2022
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.