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 - shmibs
Pages: 1 ... 78 79 [80] 81 82 ... 126
1186
« on: February 22, 2011, 07:33:32 pm »
hullo everyone. i thought a little friendly competition may be in order so as to keep our minds sharp and fingers nimble. basically someone(in this case, me) names a fairly simple challenge. this challenge has to be the creation of some game or solving of some problem that can be approached from multiple angles, and at the same time can be finished in a day of so. the "winner" (whomever's program is the favourite of the other people who participate in that round) gets to choose the next challenge(or can defer if he'd rather not, in which case whomever else wants to can propose a challenge). this is not in any way intended to be an official contest; the purpose is simply to toss around ideas and to show people how many different possible ways there are to solve a problem. because of this, language used(or even platform) don't really matter. feel free to use anything from TI BASIC to python. just keep in mind that, in order to pick a favourite, your competitors have to actually be able to run your program  ok, here is a simple one to start us off: create the most difficult, but still theoretically playable, tunnel game in existence. mine is attached below. (note, this program won't run properly in an emu, as the display method it uses relies on actual hardware. i included a screenshot anyways, though  )
1187
« on: February 21, 2011, 07:50:49 pm »
time to get dangerous...
1188
« on: February 21, 2011, 04:41:51 pm »
or maybe one could exclude the surrounding white pixels altogether?
Because there is a border of white pixels surrounding everything that is drawn, maybe one could begin the data for each line with a five bit string dictating where to start drawing pixels that aren't white(meaning that any intro stretch of more than two white pixels would yield saved space)?
This on it's own, even if you kept the two bit method for the remainder of each line past that, would shrink your bulbasaur to 208.25 bytes(an 18.6% decrease).
1189
« on: February 21, 2011, 01:50:23 pm »
i most certainly am not an expert on data compression, but i can see a fairly simple method that would shrink it a bit.
At present, each pixel is represented in the data by two bits (one to determine if the back buffer is set or reset, and one for the front buffer, yes?). Well, it looks like, in your image here, you have quite a bit of horizontal colour repetition, meaning a form of rle wouldn't be all that bad. The method I was thinking of would ascribe four bits to each pixel, the first two to determine colour and the next two to hold the number of pixels in a row of the same colour(1-4). This means that, although the data representing a single pixel is doubled, the data representing four contiguous pixels of the same colour is halved.
currently, your sprite takes up 256 bytes of data, but using this method it would be compressed to 241.5. Obviously, it's not a huge decrease(5.6%), and it may not work even this well for your larger sprites, but it's an idea.
Another possibility is, if large sections of white space are a common theme in your sprites, using this method only for white pixels and leaving other colours to the two bit method, or even using the method for every colour but black, which seems to show up mostly in a single pixel wide, form-defining barrier around the outside of your sprites and not in large areas. I don't feel like calculating these by hand right now, but I think compressing only white is the method most likely to work best on this bulbasaur.
1190
« on: February 20, 2011, 10:58:00 pm »
i'm not too late, am i?
this is Balrog, a boss from cavestory.
1191
« on: February 20, 2011, 10:04:49 pm »
ooh, shiny.
you made it an external program? does that mean programs can be jumped to and returned from during app execution?!
1192
« on: February 20, 2011, 07:42:36 pm »
yays!
this should hopefully help to clear things up. thanks for being so organised, dj.
1193
« on: February 19, 2011, 07:25:30 pm »
sorry about that i realised what i screwed up about 15 minutes after my father got on, meaning there was no way i could do anything about it until now. this actually *should* work. just make sure that none of the temp vars i use are over-writing values you need somewhere else, and, if so, reassign them. good luck. post above edited.
1194
« on: February 19, 2011, 06:56:03 pm »
yeah, i had to double take on that name Ben Ryves, for any of you who may have somehow missed it, has been working on putting Doom (or the 3d engine, at least) on the 83/4 + line via his project Nostromocongrats to Mrakoplaz for making his debut project so ridiculous!
1195
« on: February 19, 2011, 03:09:06 am »
this should do the exact same thing a bit faster. some reworking of your code structure in general would likely give you even more speed, though.
make sure you back up your current version before testing this out, in case i did something horribly wrong =D.
//variables Q-V are used as temp vars. if you need their values to be preserved for some other part of your code just reassign them to other vars/spots
.DRAWING
ClrDraw
StorePic
.BKG
conj(Pic1BK,L3,768) // back-buffered background
conj(Pic2BK,L6,768) // buffered background
G^16→S
V^16→T
V/16+{97+L4}r+GDB0→Q
0→BRepeat0
G/16+B*O+Q→R
B*16-S→U
0→ARepeat0
If {R+A}
A*16-T→V
{R+A}*32+Pic0→C
.BLOCK1 // first part of the 16x16 tile
Pt-Off(V,U,C
Pt-Off(V,U,C)r
.BLOCK2 // second part of the 16x16 tile
Pt-Off(V+8,U,C+8
Pt-Off(V+8,U,C+8)r
.BLOCK3 // third part of the 16x16 tile
Pt-Off(V,U+8,C+16
Pt-Off(V,U+8,C+16)r
.BLOCK4 // last part of the 16x16 tile
Pt-Off(V+8,U+8,C+24
Pt-Off(V+8,U+8,C+24)r
End
End!If A+1→A-7
End!If B+1→B-5
.HUD
0→L
For(I,0,11)
Pt-Off(I*8,0,Pic3HD+L
Pt-Off(I*8,0,Pic4HD+L)r
L+8→L
End
1196
« on: February 16, 2011, 10:00:40 pm »
they were all "drawn by hand", but for some i did have 16*16 full colour counterparts from zelda which i compressed into 3 colour 12*12's.
1197
« on: February 16, 2011, 09:59:05 pm »
i suppose you do have to make sure the physics are done properly...
i'm definitely eager for an update as well, though. good luck!
1198
« on: February 16, 2011, 09:57:00 pm »
i was actually planning on including them(which is why the tank is a masked sprite instead of just OR'd). my friend who is better at graphics hasn't gotten around to making any, though, and i've been busy writing code. =/
1199
« on: February 15, 2011, 10:50:13 pm »
dang, you beat me to posting this i wonder where netham is...
1200
« on: February 15, 2011, 10:44:38 pm »
yep.
right now i'm just planning on making all the enemies move first and then making all the bullets move afterwards, running each bullet's modified (x,y) positions through the enemy list to determine if there is a hit or not. this is definitely slow, but i can't think of a better way to manage it (and as long as both lists stay within a range of 3-5 at a time i think it should be fine).
Pages: 1 ... 78 79 [80] 81 82 ... 126
|
Show Posts