This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - tr1p1ea
Pages: 1 ... 17 18 [19] 20 21 ... 44
271
« on: June 24, 2013, 04:06:26 am »
I was wondering how you plan on adding doors?
272
« on: June 22, 2013, 03:53:26 am »
Yes you can switch gram at any time, scrolling is only a few lines of code so no problem
273
« on: June 20, 2013, 11:34:19 pm »
You know that is a fair point! I think the only released Zelda ive seen that used them is the demo that came with Duck's Grayscale Programming Package? There are likely other demos though.
274
« on: June 20, 2013, 06:04:50 pm »
I second the Sin+Cos tutorial, its the simplest and most relevant tutorial ive seen.
275
« on: June 20, 2013, 05:39:18 pm »
Thats correct, since in 160x240 mode only half of GRAM is needed (and you set which portion of GRAM is visible) i use the non-active half as a buffer, then switch it in when drawing is done.
276
« on: June 20, 2013, 07:07:15 am »
microsoft have always had the problem of trying to force people into using things the way *they* want it. Its about time they actually listened for once. That said, nothing is really appealing to me about any new console ... its basically same old games (will there be another 5 halo's this generation?). Also lol @ that sony video  .
277
« on: June 20, 2013, 07:04:12 am »
Well it has to be educational by the looks of it, so it could be that with the forumals or something as well?
278
« on: June 20, 2013, 06:43:41 am »
Opps i was on my phone, must have hit lock topic when trying to change pages :S.
Also the reason people use Link's Awakening is because they are 16x16 tiles im pretty sure where most other Zelda games have a higher resolution (Aside from NES etc).
279
« on: June 20, 2013, 02:20:15 am »
Flipping the LCD is pretty much like doing a fastcopy in old xLIB. So you will need to draw text twice if there is stuff moving in the background.
To further explain the getkey function:
if you just want to get the key in Ans then you can do:
real(2,0
And the key will be in Ans, the same was as its always worked.
The demo however takes advantage of the extra functionality of getkey. Namely that it can update USERVARIABLES depending on what keys are pressed:
real(2,4,4,1,-8,1,1,8,2,0,-8,3,0,8
Will add or 8 or -8 to user variables 0 or 1 depending on if up/down/left/right are pressed.
Here is a breakdown:
real(2,4,4,1,-8,1,1,8,2,0,-8,3,0,8
real( = xLIB token (for now)
2 = getkey function number
4 = number of keys to test
4 = keycode for UP
1 = USERVARIABLE 1, being used to hold playerY
-8 = value to add to USERVARIABLE 1 (playerY)
1 = keycode for DOWN
1 = userVARIABLE 1, being used to hold playerY
8 = value to add to USERVARIABLE 1 (playerY)
2 = keycode for LEFT
0 = USERVARIABLE 0, being used to hold playerX
-8 = value to add to USERVARIABLE 1 (playerX)
3 = keycode for RIGHT
0 = userVARIABLE 0, being used to hold playerX
8 = value to add to USERVARIABLE 1 (playerX)
This way you can do 4 key tests and update the variable appropriately in 1 real( statement. The reason for this is key handling was possibly the biggest reason for slowdown in BASIC games.
Currently it only supports addition, but that can be expanded. That said you would probably have your movement work like this and if you have menu keys you can process them seperately. That said the way it has always worked hasnt been taken away so the standard way to handle keys is still there.
I should mention that the lib will require very different coding techniques over previous xLIBs or other ASM libs. This is unavoidable due to the speed limitations of the platform. Here is the code for the sprite demo:
:real(1,1,0,0
:real(1,1,1,0
:real(1,1,2,0
:real(1,1,3,0
:real(1,1,4,127
:real(1,1,5,0
:real(1,1,6,0
:real(1,1,7,64
:real(0,1,0
:real(3,0,5,6,7,0,0,1
:real(3,0,5,6,7,0,0,0
:real(1,1,8,real(3,1,0,1,7
:Repeat real(2,0)=15
:real(4,0,1,8,8,0,4,239,1
:real(4,2,3,8,8,0,8,1,0
:real(1,1,8,real(3,1,0,1,7
:real(1,1,2,real(1,0,0
:real(1,1,3,real(1,0,1
:real(2,4,4,1,‾8,1,1,8,2,0,‾8,3,0,8
:End
:real(0,1,1
280
« on: June 20, 2013, 01:26:47 am »
Its virtually just an extension of the getkey command that can conditionally add/subtract a value to any user variable if the appropriate key is pressed. It saves having to do the old way of: get key value if key=?? then update variable1 if key=?? then update variable2 etc ... Also here is a screenie that demonstrates how xLIB uses GRAM to buffer graphics: 
281
« on: June 19, 2013, 07:48:25 pm »
Runer112, calc84 and i were talking about hook standards and such yesterday. A standard hook manager needs to be created; this likely wont happen for a while. There are the alternatives of OpenLib( and ExecLib( however one of the issues with this the handling of arguments, which will require excessive abuse of Ans.
With a parser hook you can effectively do things like: real(0,1,real(1,0),5 ... etc. I can use a different token if need be, but regardless of the token the hooks still need to be chained (not that there are any actual hook programs for the 84C yet).
Chaining keypresses means you can submit a list of keys to test at once, and add/subtract a value from a variable if true.
real(2,number_of_tests,key1,variable1,value1,key2,variable2,value2,key3,variable3,value3 ...
Instead of having multiple key commands. This actually speeds up things dramatically.
Also the screenie with the transparency has a better sprite routine than the first screenie which is why it is a bit faster. The gif might not be completely accurate however.
282
« on: June 19, 2013, 08:14:25 am »
Did some sprite tests on a tilemapped background:   Left screenie is with no transparency, right is with the transparent colour specified. The tilemap is drawn as a background and the sprites are drawn over it. The tile that the sprite is over is redrawn every offscreen frame to effectively 'clear' the sprite. The map is not drawn every frame, rather it serves as a background.
283
« on: June 19, 2013, 06:29:03 am »
Old version of xLIB were like that, but the long running version installs a parser hook which intercepts any real( commands.
284
« on: June 19, 2013, 05:12:05 am »
Ive thought about OpenLib/ExecLib, but i thought there were issues with using it? Ill check it out . (Also thanks for the APP info ).
285
« on: June 19, 2013, 02:20:58 am »
There is a standard 256 colour 'xLIB Palette' that graphics need to use. This is not required to be included with the sprites/PIC's themselves.
Pages: 1 ... 17 18 [19] 20 21 ... 44
|
Show Posts
