Join us on Discord!
You can help CodeWalrus stay online by donating here.
Menu

Show posts

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.

Show posts Menu

Messages - Agothro

#1
Quote from: DJ Omnimaga on January 05, 2015, 05:54:08 AM
Because by only drawing every two row of pixels, it doubles rendering speed. Remember that on a CSE, filling the entire 320x240 screen with just 1 single color takes approximately 0.25 seconds, meaning 4 images/seconds. My game runs at 20 FPS on the 6 MHz 83+.

Plus we have to take both rendering and game code speed into account anyway (for example, if this game was 288x192 with no scanlines and ran at 15 MHz on a color model, it would probably run at 8-10 FPS)

So do you just write differences to screen or the whole image?
#2
Quote from: DJ Omnimaga on January 05, 2015, 05:28:15 AM
I would say that maybe there could be a brand new Axe utilizing an identical syntax and use a computer for compiling to multiple platforms simultaneously, but on the side, someone could write a 83+ Axe to 84+CSE Axe program converter for people who just want to play older games on their color model. Actually, there could even be a converter for other calcs with no speed restrictions and the option to scale graphics up.

This is a mockup of my idea:


The first would basically be 96x128 on 160x240, while the second one would be 288x192 on 320x240.
However, this example is a 6 MHz game. Even with the Full command I doubt a CSE version would run at 100% speed, which is why I slowed down the modified screenshots above to 12 FPS instead of about 18. Perhaps the first, especially considering it's in half-res mode, would run closer to original game speed.


Nice mockup, matches my idea. Any reason to keep scanlines?
#3
Ok. Also, what problem happened with the omni admins?
#4
Site Discussion & Bug Reports / What is Black Sunday?
January 05, 2015, 04:39:43 AM
Sorry, can somebody fill me in?
#5
General Music Talk / Re: What are you listening to?
January 05, 2015, 03:15:01 AM
I've been listening to some interesting podcasts (non-musical, but ...)

Hello Internet: A podcast with CGP Grey (videocator) and Brady Haran (videojournalist), who talk about... things. Its format is called "two guys talking." If you want to listen to it, you have about 25 episodes of backlog, I highly recommend you start from the top.

Accidental Tech Podcast: This one's mainly for Apple fans. John Siracusa, Casey Liss and Marco Arment talk about Apple products, and some other things about being a professional developer (mainly on Apple platforms though).

The Talk Show with Jon Gruber: Gruber talks to people. Mainly Apple-dev related, as well.

I found these interesting.

Also, DJ, you're listening to Celine Dion? I knew you were Québecois but I didn't know you didn't have taste  ;D OK, joking a little but still, IMHO she's right up there in the "Canadian Music Hall of Shame" with Bieber and Nickelback.
#6
Nice game. It's a shame that the TI84+CSE is so slow though.

Idea: maybe add walls or other obstacles?
#7
Quote from: Art_of_camelot on January 05, 2015, 12:14:02 AM
Axe is fully compiled. If someone were to make a version of it they'd need to be very familiar with SH4 assembly for the Casio Prizm and newer 9860's. If they wanted compatibility for the older models they'd need to be familiar with whatever processor those models use as well (SH3?). As I said though, I think it's pretty unlikely.

I could perhaps write a version in C. Do you think that'd work with an nspire?
#8
Quote from: Dark Storm on January 04, 2015, 10:17:42 PM
I have some questions about Axe Parser and this possible support for Casio calcs.

Axe is an interpreted language like Basic? Or semi-compilated like Lua? Or full-compilated ?
In case of a FxCG10/20 support, remember that calc has few RAM, so it could be a limitation.
If Axe is an interpreted language, and if members (Lephenixnoir, ...) of PC success to make a grayscale engine for 9860 series, I can try to make support of Axe. As the screen is 128x64, we have enough place to draw all.

I think that Axe support could be great on Casio calculators, there are lot of games written in Axe. :)

Axe is a fully-compiled language if I recall correctly, but I could be wrong. Either that or semi-compiled.
#9
Quote from: Art_of_camelot on January 04, 2015, 10:04:06 PM
Quote from: Agothro on January 04, 2015, 09:40:50 PM
I think that from a portability standpoint, the lesser graphics modes (aka 84 mode) are a benefit because they'd allow easier porting of existing programs. And you'll recall that this is all theoretical anyway.

But, if axe could be written once, it can be written again. Maybe I'll do some work on a C version.

This is true, but then you would not be taking advantage of the target platform at all. In that case, the game would likely compare poorly from a graphical standpoint to others that were designed for the said platform.

I acknowledge this, there would be better ways to design a new game (perhaps with another theoretical graphics mode or with another toolkit), this is mainly concerning porting existing games to a playable format.

Quote from: Juju on January 04, 2015, 10:00:00 PM
Well, yeah, there's probably nothing that prevents you to do your own reimplementation of Axe if you wanted to.

Yep, that's what this is about.
#10
I think that from a portability standpoint, the lesser graphics modes (aka 84 mode) are a benefit because they'd allow easier porting of existing programs. And you'll recall that this is all theoretical anyway.

But, if axe could be written once, it can be written again. Maybe I'll do some work on a C version.
#11
That's correct Juju, the programs would still be separate. And of course programs using unsupported graphics modes would not run on calculators not supporting those modes. The advantage is not meant to be one binary, it's meant to be so that a game can be programmed once and easily ported.
#12
It's perfectly possible if you completely reimplement from scratch, which is what I suggested.
#13
Axe Parser, for the uninitiated (probably the small minority on this site) is a development tool (compiler kit) and programming language for the TI-8{3|4}+(SE) (henceforth the TI-84). Many games have been written with it. Now, those games are not easily ported to any other calculator (they have to be rewritten.)

I'm particularly interested in making a port that can run decently on an TI84+CSE. I wouldn't make it myself, since I'm not an ASM programmer (yet), but maybe one day...

Upon compilation, you'd choose a graphics mode:

Mode 0 would be the native resolution of the TI-84 (96x64)
Mode 1 could be the native resolution of the TI-84+CSE, HP Prime, nSpire CX, and  (320x240)
Mode 2 could be half resolution for the those calcs (160x120)
Mode 3 could be the native resolution of the Casio FX-CG10 (384x216)

etc.

and zoom mode could be set to 1x, 2x, etc. Lines and pixels would be doubled appropriately.

color modes:

Mode 0 would be Black and White.
Mode 1 would be 4-Gray.
Mode 2 would be 8-color. (set from a palette of colors per program)
Mode 3 would be 16-color (again set from a pallette)
Mode 4 would be 256-color. This would be enough, at least for now.

My first theoretical approach is a port to the 320x240 calcs. Let's do an example of scaling here, if we have a program written for a TI-84 originally (100% of current Axe programs)

So, let's say the mode is Graphics:0/Disp:2x/Color:1.

Let's say there's a centered display.

Pretend this image was centered well, ok?



Now, the screen BG would be set for all the other pixels before the program starts. Each cycle, the program sends blank data for all these pixels. It stores 96x64 pixels internally with 2bits/pixel, making the screen data that's rendered for each frame 12228bits, or 1536bytes. This will fit into the RAM used for buffer comfortably. Each cycle, the program will do the following for the drawing function:

For each line not in the image, you won't have to store data, so it'll output a set number of blank lines (set by the mode) and then a set number of blank pixels, followed by each pixel of the image (twice per data point), followed by some set amt of blank, new line, blanks, duplicate of last line, blanks, repeat for the other lines. I'm assuming that the pixels are not written synchronously (hopefully), or else you need more RAM. Of course, the colors (preset) will be translated on the fly per pixel (at least for now). Hopefully this sounds like it could run fast enough.

Any tips? This is purely theoretical details of implementation, and not a project per se ... yet.
#14
I can play the piano (kinda badly, although I've played for 7 years) and used to play the alto sax. I still have mine, maybe I'll pull it out during the summer if I have time.
#15
Other / Re: New member introductions: Say hello here!
January 04, 2015, 04:16:43 AM
Agothro here.

Got a TI-83+ (yep, not an 84+, an 83+) back 3 years ago for school. I learned you could play games on it, so first I typed in a BASIC program of hundreds of lines to get it working with pong. That was the beginning.

For a while I did this until my little brother took the batteries out of my 83+, meaning my hard-earned slightly modded game was gone for good. While I never had a fancy USB plugin kit, I soon started a new quest: borrowing a friend's 84+. I did this and discovered the USB support and the great amount of space, as well as fancier spect. Never have bought one, despite the fact that they're only like $5 more than an 83+.

I found MirageOS and later DoorsCS, and started using them (archive everything folks). I found Pokemon Topaz, as well as ZTetris (killed at that game in math class, my scores were in the tens of thousands)

As for my own games, I've fiddled around with doing so before but have never had success beyond a simple program where you bounce a ball against a wall. One day I want to figure out how to use Axe. I figure that assembly is beyond arcane for somebody such as I (programming experience in C(++) and, before that, Pascal) so I'm not trying (yet).
Powered by EzPortal