What about the ability to change the offset of the GRAMs? (for side-scrolling games)
» Forum
> Your Projects
Sadly the offset is actually fine, its the rest of the drawing routines that are stuff in a respective half of GRAM. I should be able to modify them however ... but will require some testing.
tr1p1ea wrote:
but i cant definitely do the return collided tile.
Did you mean can? If so, awesome! That can make blockdude more performant if I can get the keypress and the collided blocks somewhere. Then I can just use xlib for collision detection
If not...
Im working on the example BASIC RPG which helps me come up with functions to speed up gameplay.
One that im going to add is: DRAWTILEBGLIST, which will draw tiles as per a list of X/Y values. This will save time when drawing the backgrounds of onscreen sprites.
Screenie, note that the sprites dont flicker in the emu or on calc:
One that im going to add is: DRAWTILEBGLIST, which will draw tiles as per a list of X/Y values. This will save time when drawing the backgrounds of onscreen sprites.
Screenie, note that the sprites dont flicker in the emu or on calc:
I'm not sure a I fully understand the function, can you explain it more? Additionally, I was wondering about the transparent tilemap drawing--is there any chance of that being added? That way we can have layers, which would be neat.
The function enables you to draw the appropriate tile on screen given a list of X/Y coordinates. This is useful for 'restoring' a tilemap by only redrawing necessary tiles (like tiles that have been drawn over by a sprite) as opposed to redrawing the entire map (which is slow).
drawtilemap
draw sprites
drawtilebglist <-- restores screen to tilemapped state ready for new sprites
Tilemapping possibly too slow for any realworld transparent tile usage, but i can look into adding it (it will slow the mapper in general down however).
drawtilemap
draw sprites
drawtilebglist <-- restores screen to tilemapped state ready for new sprites
Tilemapping possibly too slow for any realworld transparent tile usage, but i can look into adding it (it will slow the mapper in general down however).
tr1p1ea wrote:
The function enables you to draw the appropriate tile on screen given a list of X/Y coordinates. This is useful for 'restoring' a tilemap by only redrawing necessary tiles (like tiles that have been drawn over by a sprite) as opposed to redrawing the entire map (which is slow).
drawtilemap
draw sprites
drawtilebglist <-- restores screen to tilemapped state ready for new sprites
Wait, can't you already do this? I still don't really understand.
drawtilemap
draw sprites
drawtilebglist <-- restores screen to tilemapped state ready for new sprites
Quote:
Tilemapping possibly too slow for any realworld transparent tile usage, but i can look into adding it (it will slow the mapper in general down however).
The slowdown shouldn't be too much, I wouldn't think. Just a check of the byte before you draw it, right?
Yeah you can already do it, but you can only do it for 1 tile at a time. The extra function just lets you pass in a list of coordinates for it to do in 1 pass; an extension of the routine if you will.
For transparency I would have to:
perform a dummy read
read the pixel
compare
output the pixel again (to satisfy autoincrement) if transparent, else write the tile pixel
Keeping in mind that the overhead is multiplied 19200 times for a full screen write.
I can do it though, but only if there is a strong demand.
For transparency I would have to:
perform a dummy read
read the pixel
compare
output the pixel again (to satisfy autoincrement) if transparent, else write the tile pixel
Keeping in mind that the overhead is multiplied 19200 times for a full screen write.
I can do it though, but only if there is a strong demand.
Quote:
perform a dummy read
read the pixel
compare
output the pixel again (to satisfy autoincrement) if transparent, else write the tile pixel
Keeping in mind that the overhead is multiplied 19200 times for a full screen write.
Hmm, okay. Well, what about some way to define a transparent tile? That way there can still be layers, it's just at the tile level instead of at the pixel level. It's just looking at something like Aura, it'd be a lot slower I think to manually draw the sprites with transparency themselves than it would to have a transparency-based tilemap. read the pixel
compare
output the pixel again (to satisfy autoincrement) if transparent, else write the tile pixel
Keeping in mind that the overhead is multiplied 19200 times for a full screen write.
Well I'll just branch to the appropriate tile drawing routine depending on what function is called. Ill have ordinary mapping and mapping with transparency - should be easy enough to implement .
EDIT - I have done a little more work on the enemy sprites, it can be quite challenging to get something recognizable at 8x8 and with only 2 frames for animation.
See if you can recognise: snail, beetle, jellyfish, scorpion, rat, cat, snake, crab, bat, spider & butterfly.
Still thinking up ideas to make the speed at little better (this is BASIC though).
EDIT - I have done a little more work on the enemy sprites, it can be quite challenging to get something recognizable at 8x8 and with only 2 frames for animation.
See if you can recognise: snail, beetle, jellyfish, scorpion, rat, cat, snake, crab, bat, spider & butterfly.
Still thinking up ideas to make the speed at little better (this is BASIC though).
I have to say that looks pretty darned fast, all things considered.
As to enemies, I guess it depends on what kind of RPG you are making, most don't display enemies on the overworld map, you just get shifted to a new screen to display the enemy and your battle options.
Some amazing work, as always
As to enemies, I guess it depends on what kind of RPG you are making, most don't display enemies on the overworld map, you just get shifted to a new screen to display the enemy and your battle options.
Some amazing work, as always
The jellyfish and cat are both very cute! I was able to identify all the enemies, so I think you're doing just fine as far as that goes. Are you making this just as a demo, or are you planning a full game? What's it going to be like?
It will be a full game in a sense, but something that you can complete in a very short timespan - since its merely a demonstration.
I was going to make it so that you kill the enemies while walking around and stuff to gain XP etc. It wont be a turn based RPG with all the bells and whistles. There will be a small story to follow as well.
Basically its just something to show what can be done with ASM libs on the 84C currently.
I was going to make it so that you kill the enemies while walking around and stuff to gain XP etc. It wont be a turn based RPG with all the bells and whistles. There will be a small story to follow as well.
Basically its just something to show what can be done with ASM libs on the 84C currently.
I'd like to make a request; Could I get the newer xlibc functions either posted up or messaged to me in the style that the wiki has them? I'd like to make sure LibHelper is prepped and ready to go for the DCSE 8.1 release.
I just have an issue to resolve with 2 functions and then i will outline the additions in detail for you.
Thanks a ton good sir
I'll have to set up a screenshot or two up, to show off how things look in LibHelper so you can see what all I've done with the data you've put in the wiki
I'll have to set up a screenshot or two up, to show off how things look in LibHelper so you can see what all I've done with the data you've put in the wiki
Good news, i fixed the Output( bug! Now xLIBC commands play nicely with the TIOS .
Also i discovered that returning values into a List in Ans is SLOW. So slow that it halved the fps of the xLIBC DEMO :S. But the workaround is that I now create a user-defined list call "XL" that holds all the arguments needed. This is only for the Sprite Collision routines. But I probably should port it over to the getKey->List routine as well.
Also i discovered that returning values into a List in Ans is SLOW. So slow that it halved the fps of the xLIBC DEMO :S. But the workaround is that I now create a user-defined list call "XL" that holds all the arguments needed. This is only for the Sprite Collision routines. But I probably should port it over to the getKey->List routine as well.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
» Go to Registration page
» Go to Registration page
Page 5 of 8
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement