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 - Hot_Dog
Pages: 1 ... 29 30 [31] 32 33 ... 194
451
« on: October 06, 2011, 04:16:50 pm »
prgmTHEGAME
::"YOU JUST LOST THE GAME
:Stop:"HAMMER TIME
"get this one out
:ClrHome
:1->A
:{4,7,5,8,5,6,5,7,5,9,4,8,4,9}->LGAME
:"THEGAME"->Str1
:DelVarS8->B
:For (B,1,7)
:2B->B
:Goto 4
:Lbl 4
:Goto 5
:Lbl 6
:RandInt(-9E99,9E99,999)->L1:SortA(L1
:If B>ln(5)
452
« on: October 06, 2011, 03:30:14 pm »
If you are sending lines to the screen in TI-OS manner (columns) then it won't really make a whole lot of difference.
But, if you are sending lines row by row, then yes, that will make quite a difference. The reason is because the LCD copies the data to the screen starting at the top. So, if you copy data from bottom to top, you are going to cross paths with the updater twice as often, resulting in twice the interference. In fact, if you manage to calibrate the screen perfectly, you might actually see two glitch lines at once.
It's probably a bit late for your project, but if you are dead set on updating the screen with LDD, you could update the LCD regularly but actually invert your buffer so that the top is at plotSScreen+768-12. I did that in the Impossible game (for other reasons) but it's still a valid technique.
If you are wondering, yes, I have tried to update the screen that way before, so I'm not just assuming it updates top down.
I don't think inverting is going to be hard, but I would be updating the screen from right-to-left...is that an issue?
453
« on: October 06, 2011, 01:53:30 pm »
Let's say that I have a routine that lets a user calibrate their grayscale in an attempt to get rid of the scan line.
Although unusual, I'm hoping to copy plotsscreen to the screen backwards, that is, from (plotsscreen + 767) to (plotsscreen). I'm doing this because I want to take advantage of the fact that ldd will decrease BC like it does HL and DE. (LDI sends HL, DE and BC in opposite directions) However, will this cause problems with grayscale due to the scanline, even if a person has calibrated the screen?
454
« on: October 06, 2011, 01:34:19 pm »
Is there a specific format I could make a map in? I want to help.
Oh, didn't you get my PM? Maybe I didn't send it, my bad. Please feel free to look at the topic below for more details  http://ourl.ca/12998
455
« on: October 06, 2011, 12:25:37 am »
Hot Dog, I've been getting some odd errors with crabcake with the new Axe, so if you have time could you look into it for me?
The program compiles and runs fine, but crashes on exit.
Sometimes Axe throws a "Token" error, but error goes away eventually.
Thanks in advance ^^
It would help if I could have a go at the program you're creating, along with some more information.
456
« on: October 05, 2011, 09:32:25 pm »
Change of plans!
As some of you may know, the Ti-83+ SE/84+ screen is slow, and so I'm coming up with creative ways to use the time required to output data to the screen. This should help speed up the game.
457
« on: October 05, 2011, 09:09:43 pm »
Scenery in bunches that make sense are good. Random lonely scenery is not.
I'll definitely keep that in mind, but you'd be surprised how often lonely, random scenery comes up in other games or the real world. Especially to keep processing power down 
458
« on: October 05, 2011, 04:00:11 pm »
If the scenery was all gray except for wall outlines, which are black, and then enemies are black, they would be more visible.
Ah, I gotcha. Well, as much as I hate the idea of grey scenery, that might be an option
459
« on: October 04, 2011, 09:44:45 pm »
What about making scenery gray so you know when you see an enemy? that way you can't see them behind walls.
Can you rephrase? I'm confused.
461
« on: October 04, 2011, 12:33:14 pm »
hmm.. how about everything except for enemies are grey and enimies are black? But some meemies will be grey to fool you...
And/or enemies should meve more so it is more evident. If you make that the case, they should be a little easier to kill.
Those are both good ideas, so I'll try both. Although I'm going to make the enemies, not the objects, gray. Also, the moving around faster might make it hard for a player to aim...I've played this on actual hardware, and it's not easy as it is.
462
« on: October 04, 2011, 12:05:36 am »
I've been looking for a game which does a really good job at letting someone design a transit system and then just letting it run--making adjustments from time to time to make money. Ideas?
I tried Traffic Giant and it doesn't work on my computer.
463
« on: October 03, 2011, 09:46:46 pm »
How about only having enimies? scenery never looks good until you are a foot away from it. It is like your character is nearsighted 
Granted! But I'm not ready to give it up. Even if you have to be close to scenery to see it, it adds a pretty touch as opposed to a map that has nothing but walls.
464
« on: October 02, 2011, 04:26:03 pm »
To keep it from ruining the element of surprise, perhaps you should only draw arrows when the enemies are close to the center of the screen.
That's a good idea. After all, now that there's some way for someone to tell an enemy, I don't have to worry about people having to fire blindly
465
« on: October 02, 2011, 02:59:14 pm »
I started this topic because I've had some people telling me that enemies are hard to see because they show up as "pixelated blobs." Sooner or later, we might have to live with that. But until then, I've been brainstorming ideas, and calc84maniac was a help as well. I started this topic so that I can show some things I tried out and get opinions on them.
IDEA 1: Stop thickening enemy textures.
I always thickened the lines that I used to draw enemies so that the player could see them. However, they do make it hard to tell what's an enemy and what's an object, so I plan later on thinning the lines and instead adding more detail. BUT, enemies still appear defragmented from a distance, same as other objects. How can you tell one distorted object from another?
IDEA 2: Show a player that the object is an enemy, not a spaceship or a tree
At the moment, this is what I need an opinion of. You can see in the screenshot below that every enemy has a gray arrow above it. That way you can see from far away that an object is an enemy instead of something else. Right now it's a proof of concept, because I have to remove a couple of bugs where the arrow shows an enemy behind a wall
Pages: 1 ... 29 30 [31] 32 33 ... 194
|
Show Posts
